On 06/25/2015 04:58 AM, Stephan Mueller wrote: > Hi Tadeusz, > > I do have a few questions around the akcipher API. > > The API offers access to the raw asym encryption and decryption operations. > > The "normal" use of asym ciphers is the hybrid mode. That opens the following > questions: > > - how would a hardware implementation offering only a hybrid asym cipher > implementation (i.e. a full signature mechanism or bulk data encryption > mechanism) be usable via that API? Usually the HW offers acceleration for encryption primitives. To support the encryption schemes we can introduce templates for instance pkcs1_v15(rsa) or oaep(rsa) as it was proposed by Horia Geanta. > > - currently I only see one user in the kernel for asym ciphers: the module > signing mechanism. Do you expect more to come? Or am I missing others? > > - If no, then it sounds like that the akcipher API is a means to make asym > ciphers implemented in hardware and only accessible from supervisor state > available. I would assume that the majority of the users that may be > interested in that kind of support resides in user space. Is the intention to > develop an AF_ALG interface (note, I personally already thought about that > subject for some time now)? Yes, that's the main use case for this. We want to be able to accelerate SSL handshakes. > > - If user space shall also be able to use akcipher, how do you think that > should be handled in general? Should user space simply have access to the raw > asym ciphers and use that together with the hashes/sym ciphers to implement > the hybrid system? Or shall the kernel interface extend the skcipher/hash > interface with an akcipher wrapper for the hybrid system? I am currently not > sure which is better considering: > > - raw asym interface: pro: lean, most flexible; con: user land must > know of sym key (i.e. it is located in two places), potentially more round > trips between kernel/user land > > - hybrid cipher interface: just take the opposite of the raw asym > interface > > - If the hybrid system is intended to be implemented in the kernel, would then > the ton of different padding schemes need to be implemented in the kernel side > or should user space do the padding? I would think they could stay in user > land (provided that there is no kernel space user). Ideally or the padding and hashing should be done by user space and only the expensive operations like modular exponentiation should be offloaded to HW via PF_ALG and akcipher. regards, T -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
