Thus spake Dr S N Henson: > > Maybe. It would be good to the the CFB and OFB modes working properly in > general for other numbers of bits.
The code for this is trivial; define me an API and I'll write the code underneath. > 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. I'd like to see exactly where the performace problem was; I can't imagien it'd be statistically significant. > 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. All of these optimizations seem to revolve around endianness problems or char/uint64 representations. > 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. I tried this for AES and got ~10% speed increase for CBC in about 5 minutes using some generic assembly. Another 17% by throwing some MMX stuff in over my lunch hour. And I haven't even touched the C algorithm itself :) Again, it's not worth doing this for each algorithm/mode, but if we had either a mode API or at least macro sets, it would be. S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
