Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 02:10:00PM +0200, Patrick Lamaizi?re wrote:
Le Sun, 20 Jul 2008 21:39:55 +0200,
Pawel Jakub Dawidek <[EMAIL PROTECTED]> 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?
Can't help here, no idea. Eventhough it isn't something I'd like to see
implemented. 'maxoplen' is just a little better than what we have now.
And what if a driver supports 192 or 256 bits only?
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.
There are many improvements that could be done in opencrypto framework,
believe me. One of the things that annoys me a lot is that if you want
to use IPsec with a driver that support only encryption, you have to
implement hash functions in software for the given driver.
Feel free to work on this, but be sure to avoid solutions like this
maxoplen thing, which bascially isn't really a step further. Choosing
another driver on newsession failure sounds reasonable, although we may
lose informations like 'the caller wanted hardware crypto only'.
I've lost track of the history behind maxoplen. As Pawel says a max
parameter is only minimally useful in describing device capabilities.
My main comment is that I used to consider it important to maintain
interoperability w/ obsd for the sake of sharing work. However we've
long since diverged such that it's infeasible so revamping api's is fair
game. If people want to work on the crypto framework that'd be great;
they might also take a look at Thor's netbsd work to improve performance
of applications that use /dev/crypto (e.g. openssl).
Sam
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
