On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote: > > Ohh, I see. So, you are saying that there should not be a setpub/privkey for > the akcipher AF_ALG interface?! > > If somebody wants to use akcipher, he shall set the key via the keyring and > akcipher shall obtain it from the keyring? > > However, for the actual data shoveling, AF_ALG should still be used? That might seem ideal, but Herbert doesn't want that — he wants akcipher to work *only* with its own internal keys, not with keys from the kernel's key subsystem. David has patches (not upstream yet; used for testing) which expose a verify operation for kernel keys through sys_keyctl(). Adding the other three operations would be feasible. Perhaps if we *really* want this to appear through AF_ALG, the key subsystem could register its own RSA (and other) implementation(s) with the crypto subsystem. Then we could find some way that we can pass the key_serial_t through alg_setkey() instead of the actual key data without it (or Herbert) noticing that's what we're doing. But... ick. And I don't think we can select algorithms based on the actual key rather than the type. We should do it properly, if at all. And define the API as taking key IDs instead of having it be a nasty special-case hack for a specific (but really, very generic) algorithm provider. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
