On Mon, Apr 30, 2012 at 6:16 PM, Niels Möller nisse@lysator.liu.se wrote:
and one could then "subclass" that as struct rsa_private_key_blinding { struct rsa_private_key super; struct whatever_random_ctx_needed ctx; };
It might be too complicated for a low level library. If all those were hidden from applications it would be all right, but this complication will lead to a moment where something has to be changed/updated/added. I'd suggest to keep the low level interface as simple.
(not sure this is the best design, but it's one possibility). Now I have a question: Would it be feasible to support smartcards (and similar hardware) at the same time? Then the secret key wouldn't be available at all to nettle, and a signature function might have an interface like> int rsa_sha1_sign(rsa_compute_root_func *f, void *private, struct sha1_ctx *hash, mpz_t signature);
Then you'd need to cope with smart card drivers and all. Opensc does all that and provides a pkcs11 interface. All (or most) commercial smart cards also provide a pkcs11 interface. So I'd expect that applications that do that, already use it (we do it in gnutls and the high level functions abstract between keys in software -> nettle and keys in hardware -> pkcs11).
where the actual private key data is totally dependent on the smartcard and its interface software. But what interfaces do typical smartcards use? Do they allow you to compute an arbitrary rsa root, or do they only more specific operations like "pkcs#1 v1.5 decrypt", "pkcs#1 v1.5 sha1 sign", #pkcs#1 v2.0 sha256 sign"?
They can do either, depending on the capabilities of the card.
I want to figure out if smartcard support at this level is at all feasible. If not, we have to leave that for applications and libraries on top of nettle, and then the nettle interface should be tailored for software keys only.
I think it would make sense for a high level interface.
regards, Nikos