Thus spake "David Maurus" <[EMAIL PROTECTED]> > Stephen Sprunk wrote: > >In the specification of CTR mode, as proposed for AES, you will find the > >statement "The number /nonce/ is incremented following each encryption." > >I interpreted this to mean that the top 2^64 bits are to be incremented for > >each successive block, and this is how I implemented the code. > > > I assume that 'number /nonce/' should mean the result of the > concatenated parts of the IV.
No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers to the top 64 bits and 'ctr' refers to the lower 64 bits. > In case of the AES-CTR IPSec draft, you get the IV by concatenating > a msg number, a nonce, and the counter (at start initialized to 0). You > can then safely incerement the 128 bit IV, *unless* you overflow the > counter part (the lower 32 bits of the IV, according to the AES-CTR > IPSec draft). NIST's version does not have a message number, and the counter is 64 bits. > >On the matter of overflowing the lower 64 bits, this is not specifically > >addressed in the submission (I think they assumed nobody would exceed 2^64 > >blocks per stream, which is reasonable) and thus I think wrapping is the > >correct failure. > > > I'm not sure what you mean with 'the correct failure', but the clean way > to handle a counter overflow would be to fail / report an error, instead > of continuing to encrypt. Unfortunately, the current API has no way to report "no more encryption possible, you must rekey". Given this limitation, two silent failure modes are possible: either wrap and reuse ctr values, or don't wrap and use nonce values the user didn't specify. The former is obviously bad, but IMHO the latter is equally bad. > This discussion is academic for 64 bit counters, of course, as you > probably won't see a 64 bit counter wrap very often. With a 32 bit > counter however, the risk is a lot higher. Unfortunately, the current > basic crypto functions offered by OpenSSL don't support returning an > error condition, so 'failing' is not an option anyway. 64bit counters allow 256EB to be encrypted with a single key, and even at today's maximum link speed of 10Gb/s, that's just under 69,731 years of data. Famous last words perhaps, but I think we can safely ignore that problem. 32bit counters can wrap in under a minute; IPsec clearly has a pressing problem, but I'm not sure how to code to support both without giving up and making the ctr-increment function a user parameter. > >To increment the nonce introduces a more insidious failure > >mode where the user unintentionally reuses nonces. > > > It is debatable whether wrapping the counter would be less bad than > incrementing the nonce part. A wrapping counter is more predictable for > an attacker (as it would occur *always* when the communication exceeds > 2**32 or 2 **64 blocks) than an unlucky nonce choice. In other words: If > we let the counter wrap, the user is always affected when the counter > overflows, and the weak spot is predictable. If we allow to increment > the nonce instead of wrapping the counter, the user is only affected > when the counter overflows, *and* he continues to reuse the same key but > chooses a new nonce, *and* the choosen nonce value collides with the > incremented nonce. Per the NIST spec, the next nonce chosen will be the old nonce plus one, so the user's choice will always be "unlucky". > >Unfortunately, implementing this (as has been requested) would require > >more significant changes to the API than I know how to make,as passing > >parameters to a mode doesn't appear to be supported today. > > 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. While this option is tempting, and the user does have access to the counter at all times to check for impending overflow, experience shows that programmers ignore such warnings more often than not. 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]
