Alexander S A Kjeldaas wrote:
>
<snip>
> Although I think using separate header files is ok, I do not see an
> advantage in this case. Why optimize on an extremely remotely
> probable case - that the following happens:
>
It's not for optimizing something, except the case of readable code.
There's a lot of redundancy in the source as is and that is bad for
maintainability. We already have a dozen ciphers and two hash functions
in the API, adding RIPEMD, Tiger and SHA-256, -384 and -512 is just a
matter of time. I just experienced what is takes to go through all
cipher files by hand and changing similar things in each of them. Ugh.
Don't want to do that for 20 ciphers and 10 digests.
IMO we should not change the code for something that might come or might
not come in the future. No-one has to my knowledge made a move to use
the ciphers directly. The current usage is confined to the API and the
purpose of an API is to simplify the interface. If we let THEM use the
ciphers directly, why do we want to have a crypto-api at all? Let them
use the ciphers directly. Sorry.
Let's just wait for the first poor soul that wants to use the ciphers
directly. Make him submit the necessary changes, exporting all those
symbols and then let him watch the CryptoAPI selecting the fastest
implementation of a given cipher at run time and he'll probably will go
back to using the API. That's what it's for.
Imagine crypto.h with the following contained in it for a two dozen
ciphers:
cipher_mode0_encrypt (..)
cipher_mode0_decrypt (..)
:
cipher_mode5_encrypt (..)
cipher_mode5_decrypt (..)
cipher_set_key (..)
Let there be various size/speed tradeoffs:
twofish_zerokeying_ecb_encypt ()
:
twofish_compile_ecb_encrypt ()
::
This is also the reason why we might want to add a _separate_ mode layer
in the near future instead of the gen-mode.h method.
Marc
--
Marc Mutz <Marc@xxxxxxxx> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
