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]
