akcipher API: plans

akcipher API: plans

[Stephan Mueller]

Hi Herbert, Tadeusz,

in various emails, I think I have seen several concerns or change requests 
regarding the akcipher API. As all of those apply to the AF_ALG interface for 
akcipher too (which I try to get straight), I would like to ask for potential 
plans of the discussed areas if there are any. If there is no plan, may I ask 
for a discussion on what would be the best way forward.

Also, considering the conversion of the module signing code to use akcipher, I 
feel, we should get the API sorted out to avoid much transition work in 
"users" of the API as well as cipher implementations.

For the following areas, I saw discussions (if I have overlooked an item, 
please add it):

- 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). 

- 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.

- 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.

Ciao
Stephan

Re: akcipher API: plans

[Herbert Xu]

On Wed, Aug 26, 2015 at 10:38:24AM +0200, Stephan Mueller 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.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: akcipher API: plans

[Tadeusz Struk]

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