On Tue, Oct 17, 2000 at 03:52:43PM +0000, Marc Mutz wrote:
> Hi!
>
> I've noticed that quite a lot of stuff in crypto.h is unneeded. In
> particular, all the encrypt/decrypt/set_key declarations don't need to
> be there, since the symbols aren't exported anyway and placing them in
> the crypto.h file might make people do the wrong thing and calling them
> directly.
I agree that we need some changes, but I think going the other way is
better :-). Keep the functions in crypto.h, but add even more.
Include the *_cbc and *_ecb versions, and wrap the various
declarations in #ifdef CONFIG_CIPHER_XXX ... #endif pairs. That way,
if the cipher is compiled in, and some part of the kernel that
explicitly requires 3des for instance will not have to incur the (very
small) performance penalty of calling the function through the
function pointer in cipher_implementation. If there is a potential
performance win of calling the functions directly, I think that option
should be available. For instance, freeswan does not really win a lot
by using the crypto API before other parts of their system supports
specifying alternative ciphers. So they could use
des_ede3_encrypt_cbc directly. Or the crypto API could provide inline
functions that emulate libdes.
>
> I have also added a little description of the meaning of the
> CIPHER_KEYSIZE_* constants, and a CIPHER_ECB and CIPHER_CTR to accopany
> CIPHER_CBC, which should rather be CIPHER_MODE_CBC.
>
> This patch does not touch anything except crypto.h. This is the reason
> that *_KEY_SCHEULE_SIZE is still alive. After all, it is exported via
> the cipher_implementation structure of each cipher and only used in the
> module implementing the cipher. It was best to create a struct
> CIPHERNAME_context for each cipher and use sizeof(CIPHERNAME_context)
> to determine CIPHERNAME_KEY_SCHEDULE_SIZE.
The *_KEY_SCHEDULE_SIZE definitions are a tradeoff between clutter in
crypto.h, and availability of low-level information on the ciphers.
Adding a
struct des_ede3_context { ... };
#define DES_EDE3_KEY_SCHEDULE_SIZE sizeof(struct des_ede_context)
is probably a good idea to make sure things are in sync. But as I
said I would like to keep stuff in crypto.h to make the low-level
functions available if someone wants to use them.
> Also, the size parameter can be dropped from the vanilla
> encrypt/decrypt routines, now that we have *_ecb_encrypt. After all,
> those functions were supposed to only encrypt one block at a time.
Agreed.
> All this would be confined 'below the surface', i.e. would require no
> change to the user-side API. The following changes would affect the
> user-side API:
>
> In the next step, we could get rid of exporting that number entirely and
> make set_key or the constuct() method below allocate the required memory
> and fill in the keyinfo pointer into struct cipher_context.
> Then we could move the lock() and unlock() methods into constuct() and
> destruct() methods, resp. where the keyinfo memory could be freed in
> destruct(). This makes for a nice object-oriented API. The current
> version is almost there, but the caller needs too much information about
> the cipher, IMO.
>
> For all implementations of digests/ciphers in the current kerneli, the
> constructors and destructors would be no-ops except for calling lock(),
> unlock() and kfree(). For future hw crypto accelerators, however, the
> use of constructors and destructors would enable them to set up quite
> complicated data structures, such as wait queues, to handle concurrent
> accesses or to wake the hw from a powersave mode.
>
I also think we need something like constructors and destructors for
"transform_contexts" which basically becomes an opaque type.
> The constructors could be loaded with all the things that need to be
> (re-)defined only seldomly, if at all:
>
> o block size (for ciphers that support variable block sizes, e.g. AES)
> o key length (dto.)
> o mode (either ECB or CBC or Counter or...)
> o encryption/keysetup speed tradeoffs. (??)
> etc.
>
> set_key() would then only accept a pointer to the key. This could also
> speed up implementations where re-keying can be done faster than an
> initial key-setup (e.g. twofish's 'compiled' option).
I am not sure I follow you. Could you expand on this with example
function prototypes?
set_key is currently:
cipherXYZ_set_key)(struct cipher_context *cx,
unsigned char *key, int key_len);
so in the case of a rekeying, it should be able to access the previous
key. No change of interface needed. However, something would have to
be done to make it know when to ignore the previously set key.
astor
--
Alexander Kjeldaas Mail: astor@xxxxxxx
finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key.
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
