crypto(9) and maxoplen

[Patrick Lamaizière]

Le Sun, 20 Jul 2008 21:39:55 +0200,
Pawel Jakub Dawidek <pjd at FreeBSD.org> a écrit :

Hello,

> > In the "opencrypto framework" the function crypto_register() has an
> > argument 'maxoplen'.
> > 
> > http://fxr.watson.org/fxr/source/opencrypto/crypto.c#L625
> > 
> > Does somebody know what was the goal of this parameter? It is not
> > used by the framework.
> > 
> > The man page of crypto(9) says :
> > For each algorithm the driver supports, it must then call
> > crypto_register(). The first two arguments are the driver and
> > algorithm identifiers.  The next two arguments specify the largest
> > possible operator length (in bits, important for public key
> > operations) and flags for this algorithm.
> > 
> > I'm asking if it can help for this problem: the glxsb driver can
> > perform AES-CBC algorithm only with 128 bits key and may be
> > 'maxoplen' was intended for this case. 
> > 
> > Without something to specify the key's length, the driver is
> > selected by the framework even with keys != 128 bits. So it fails
> > when the session is opened. This prevents setkey/ipsec to work with
> > key length != 128 bits if the driver is loaded.
> 
> If I read code properly, there is currently no way for a driver to say
> to the opencrypto framework that only AES-CBC with 128bit key is
> supported. A driver can only state that it supports AES-CBC, that's
> all. As a workaround the driver should implement AES-CBC-192 and
> AES-CBC-256 in software.

Yes, but my question is about the maxoplen parameter. Was it intended
for this case? Why we keep this parameter?

IMHO, It is far easier to hack the OCF to use this parameter than
to implement a workaround. It would be a better solution, by
sample we may want to use the driver for AES-128 and another
hardware that provides AES 192/256.

Another (the best?) solution would be for the crypto framework to select
another driver if the driver's newsession() fails.

Regards.