My reading of Rogaway's CTR submission was a nonce in the top half of the counter with a simple increment (by one) of the whole counter. Is there a new spec we need to comply with?
What is the correct behavior of CTR when it reaches 2^64 (or whatever lower limit IPsec et al may set)? I'd assumed that it was safe to wrap to zero and keep counting. Do you have a suggested implementation for how to set a lower limit? The modes should probably be written as macros, yes. Unfortunately, some cipher implementations don't call an ECB function but actually implement the cipher inside the mode; switching to mode macros will be very tricky. S Thus spake John Viega: > It should be possible to replace the counter increment function. > The new NIST modes doc doesn't specify a mandatory increment function, > but it does recommend one that's different from "add one every time". > > Additionally, a lot of stuff built on counter mode is using a few bits > of the counter for other purposes, so the effective counter size is > less than the actual counter size. It would be nice to be able to add > some sort of parameter that specifies the actual counter size, to > prevent counter mode from continuing to encrypt when it's run out of > counters. > > Also, why isn't counter mode implemented in a generic fashion? It's > so simple, it should be usable with any block cipher without having to > write additional code. > > > John > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- 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]
