Thus spake "Thierry Boivin" <[EMAIL PROTECTED]> > I agree with this approach which leaves the crypto library very open and > not to complex to manipulate, whatever the upper program to develop is. > > Generalized approach : as differencies for the various applications are the > way to build the IV, ie: nonce part /upper counter part / lower counter > part /whatever part, and, in my opinion, not the way to increment such a > global IV from block to block, I would make the library incrementing by > one on the whole size of the IV, leaving boundaries aspects (the routine > just don't care about the way the given IV was built) and associated > overflow condition checks (the routine gives back the manipulated IV) to > the responsability of the calling programs.
I'm thinking this is the best general solution we can hope for. Also, we should explicitly include in the docs a warning to check the IV for overflow iff the counter is <64 bits. Richard, do you want me to write up the code change, or do you want to do it? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
