At 12:21 24/06/03 -0400, you wrote:
>> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] Behalf Of David Maurus >> Sent: Tuesday, June 24, 2003 7:29 AM >> To: [EMAIL PROTECTED] >> Subject: Re: AES counter mode >> >> The easiest way to go about it would be to increment the user >> supplied >> IV by 1 for each encrypted block, and leave it to the user of this >> function to make sure that no overflow in the counter can occur. This >> obligation to the programmer should be written somewhere in >> big letters >> ;-) (i.e. DON'T USE COUNTER MODE TO ENCRYPT MORE THAN 2**32 >> [or 2**64, >> depending on the counter size] BLOCKS WITH THE SAME KEY!). >> Higher level >> routines, i.e. the SSL BIO, should avoid counter overflows >> automatically >> for the user by initiating a rehandshake. > >Agreed, just increment the user supplied IV, it's the most general approach >and will work for all the protocols that need ctr mode but can't (shouldn't) >agree on nounce/counter boundries. > >-lee 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. Thierry Boivin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
