Stephen Sprunk wrote: > > Thus spake Richard Levitte - VMS Whacker: > > > > The current state is EAY legacy. His idea was that one should be able > > to pick out any of the algorithm directories and create a separate > > library for them (the old libdes is actually exactly the same as > > crypto/des/). > > First of all, do we still think that's necessary, given the wide > acceptance of OpenSSL and libcrypto? >
I'm not too bothered by that. We've been advising people to avoid the low level API where possible for a while now. > In either case, it shouldn't be that difficult to develop a macro set > that implements various modes. Pass in some function names, block > size, types for casts, and let it generate the boilerplate. Worth > doing? > Maybe. It would be good to the the CFB and OFB modes working properly in general for other numbers of bits. I thought about moving the whole cipher mode handling to the EVP layer and trimming down the individual block ciphers to just encrypt/decrypt a single block at one point. However tests suggested that this would have a considerably impact on performance so we're probably stuck with the duplicate mode code for now. There is some duplication in individual cipher modes and some macros might help though there is some variation where some cipher optimize the storing of things like the IV in the most effective internal format. I wonder if we could do better by moving some of the mode handling to the assembly language routines and take advantage of some special cases to avoid function call overhead. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
