CryptoAPI ideas

[Michal Ludvig]

Hi all,

now that we have this shiny new mailing list up and first subscribers in 
it's time for some traffic :-)

Let me summarize some of my thoughts:

1) The API needs to be extended. I hit a major barrier while adding 
support for AES cipher provied by VIA PadLock ACE. To exploit most of 
the PadLock potential it's necessary to let it encrypt a whole buffer of 
data at once using a given mode. E.g. encrypt a disk sector (512 Bytes) 
in a CBC mode. This is apparently impossible with the current API where 
only functions for encryption/decryption of one cipher-block (typically 
8 or 16 Bytes) can be specified (either SW or HW), but the block 
chaining is always done in software. I think that PadLock is not the 
only engine that could also do the chaining in hardware, i.e. much 
faster. That's why I added new fields to the cipher_alg structure that 
could be filled in by the hw crypto engine driver and if used, 
cipher.c:crypt() will call these methods instead of the software 
chaining and encryption for each cipher block. Does anyone have a better 
idea how to let the hardware process the whole buffer at once?

2) Hardware crypto engines are becoming popular. This leads to a kind of 
conflict among the crypto drivers. E.g. there is a generic software AES 
written in C, hardware AES implemented in the PadLock and a recently 
announced i586-optimized AES in assembler. We need a way to compile all 
of them but use the fastest one only. One approach could be some 
"prioritization" of the drivers for the same algorithm. E.g. any 
hardware driver would be a best choice. Then e.g. any CPU-optimized one 
and if neither them worked, the generic C-language sw implementation is 
used. Here I consider the generic implementations (as currently found in 
crypto/) being drivers for the "software device", while e.g. the padlock 
has a driver for the hardware device. But from the point of CryptoAPI 
they should be almost equal - simply a driver providing a given algorithm.

For this I extended the crypto_alg structure by adding a cra_preference 
field. With this all the three AES modules can be loaded into the 
kernel, but only the one with the highest cra_preference will be used. 
I.e. padlock could have something like PREF_HARDWARE (=2), i586-aes 
could have PREF_OPTIMIZED (=1) and generic one will stay with 
PREF_GENERIC (=0).
Again - does anybody have a better idea?

3) As stated above I consider all providers (drivers) of the given 
algorithm equal. I don't see a reason for splitting them to 
arch/<arch>/crypto directories. IMHO much better place would be 
drivers/crypto or something like crypto/devices. OK, at the moment we 
only have support for CPU-dependent engines (z990, i586 and PadLock), 
but there are numerous PCI crypto cards that will sooner or later be 
supported by linux as well. These won't fit to any of the arch/.... 
slots. It's easy to offer only the appropriate CPU-dependent drivers 
during kernel config even if they are out of arch/.../crypto. In other 
words - I'd keep all crypto drivers in one place, preferably in 
drivers/crypto.  Maybe I'd go even further and move the generic drivers 
there as well.

Any comments on this topic?

Here you can download the patches that implement most of the ideas just 
presented: http://www.logix.cz/michal/devel/padlock/
The one called crypto-api-2.6.5.diff contains the changes for #1 and #2, 
the one called crypto-dev-padlock-2.6.5.diff is a driver for VIA PadLock 
(for now residing in crypto/devices not in drivers/crypto, but that's a 
trivial change).

Looking forward to hear any feedback ;-)

Michal Ludvig