Hi, http://archives.seul.org/mixminion/cvs/May-2002/msg00072.html shows that the problem seems to have been submitted to the openssl team one year ago.I agree with Nick and go to the same conclusion : as the openssl aes counter mode routines wants to count by 2**64 instead of by 1, the current implementation is not correct.
The source of disagreement seems to be the interpretation of a NIST document (Michael pointed such a document when replying at first). My understanding of this one is (in a practical perspective) is : calling programs maintain a 64 bit long nonce counter. This counter is to be incremented by one from messages to messages. As this nonce is used to form the high part of a 128 bit long counter value -- we add 0 for the low part -- , the "counter" element is globally incremented by 2**64 from messages to messages. This is for the behavior of the calling program. If considering the routine implementing the message encryption (so the openssl routine), message is to be split into blocks and each block encrypted with a specific counter value : first block is used with the initial counter given by the application (64 bit long value <<64 + 64 bit long zeros.). Next blocks of the message are then encrypted using a "counter value of blockN = counter value of blokcN-1 + 1" operation. --> the AES_ctr128_inc routine, called internally on a block per block basis, should therefore use a +1 operator instead of its current +2**64 operator. Thierry Boivin >Date: Wed, 11 Jun 2003 08:06:34 +0200 >To: [EMAIL PROTECTED] >From: Thierry Boivin <[EMAIL PROTECTED]> >Subject: Re: AES counter mode > >At 07:48 10/06/03 -0700, you wrote: >>Thierry Boivin wrote: >>>I agree with you about the way to build the initial "ctr" value from the "nonce" >>>value. My question is different : whithin the encryption of a whole plaintext >>>message (so a big block to be divided into 128 bit length blocks) , why to >>>increment ctr by 2^64 instead of 1 from block to block ? >>>My understanding of the operation is : >>>- increment nonce by one from messages to messages (so this is a 2^64 step if >>>considering ctr) >>>- but for each message: >>> - build initial ctr from the nonce value >>> - increment ctr by 1 from block to block >> >> >>C'est votre compréhension et non votre accord que nous attendons! >>Incrementing by 2^64 is incrementing the most significant 64-bit word by 1. > >Yes, but my point is "why does the routine increment by 2^64" ? Because the routine >is called on a block per block basis, i was expecting a +1 step instead of such a >+2^64 step. > >For those who do not only expect "comprehension et non votre accord", note that >patching the code in such a purpose allows the library to be compliant with reference >vectors given in : > >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt > >modified code : > >/* increment low part of a 128 bit counter by 1 */ >/* big endian representation */ >static void AES_ctr128_inc(unsigned char *counter) { > unsigned long c; > > c = GETU32(counter + 12); > c++; > PUTU32(counter + 12, c); > > /* if no overflow, we're done */ > if (c) > return; > > c = GETU32(counter + 8); > c++; > PUTU32(counter + 8, c); >} > >Thierry Boivin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
