Am Mittwoch, 22. Juli 2015, 09:32:41 schrieb Herbert Xu: Hi Herbert, > > I think we should finish the conversion of the only in-kernel > user of RSA before we add the user-space interface. Otherwise > this unnecessarily ties our hands to the current API. Agreed. After my question around the SGL vs linear buffers I was under the impression that it was decided. So I will wait until the discussion is completed. > > For example, do we want an SG interface for the input and output? The question is whether the SGL overhead is still acceptable for the small buffer size we have to consider when talking about raw asymmetric ciphers. For RSA, it seems that the max size 4096 bits for the generic implementation. For other implementations, I would not expect much larger sizes. Thus, we talk about 512 bytes or one 1kbytes maximum operation size. When ECC comes into picture, the sizes are even significanly smaller. If I understood correctly, we do not want to support full hybrid asymmetric operations (like PKCS1, OAEP and the like) where large buffers are to be handled. On the other hand, what about using struct scatterlist as the API input parameter. In addition, we allow cipher implementations to traverse only one SG entry which implies a linear buffer operation. But the API is open for full SG operation if needed in the future. To inform the caller about the minimum size of an SG entry, we may use another integer value similar to alignmask. So, if Tadeusz's hardware wants one linear buffer, the integer is 256 or 512 where the caller must create the buffers of at least this size. As all input data would fit into that one buffer, there the caller only needs to allocate one SG. -- Ciao Stephan -- 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