Hi, On 08/26/2015 06:51 AM, Herbert Xu wrote: >> - Type of input data: currently, the akcipher API uses linear buffers. The >> > question was raised to convert it to scatter lists. Linear buffers were seen >> > as appropriate as the data to be operated on is usually quite small. However, >> > some hardware seems to support scatter lists (CAAM was mentioned). > I think an SG interface makes sense even if today's algorithms > don't need it. The user-space interface is naturally SG based > for example. > >> > - Split of setkey into public/private setkey function. The current >> > implementation provides ASN.1 structure that allows setting all three >> > components forming a public and private key. However, considering the next >> > bullet, a split int pub/priv key may need to be considered. > I think this makes sense too. > >> > - Structure of keys: The current ASN.1 structure is used solely in the kernel. >> > Thus, DER keys generated in user space (like by OpenSSL) can only be loaded >> > after a conversion. To support such DER keys out of the box, I think only the >> > ASN.1 definition must be changed. In addition, the setkey function must be >> > split as the ASN.1 structures of a DER pub and private key are completely >> > different. > Ditto. So I'll rework the API to accommodate your suggestion. I don't really see how sgl support would be beneficial for buffers that will never be bigger that one page (in most cases they will not be bigger than 512 bytes) but if you think that the way to go I fine with that. The split for private and public set_key functions, even though is not needed for RSA (I think) might be required for other asymmetric algorithms, so I'll change it. For RSA I still think I can get both working on existing interface and with the same ASN.1 definition. Thanks for your feedback. 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
