>800-38A essentially says "up to impementator," doesn't it? >"The standard incrementing function can apply either to an entire block >or to a part of a block."
Hmmm OK I do see you point here. I was sure I'd seen a discussion on the net about this saying that it was dangerous to (e.g.) start the counter at zero, and that a nonce should be built in, and that this part should remain constant. But, now that I've gone searching for it again I can't find it :-( I wonder why RFC3686 goes to the lengths it does to specify such a complex counter block with only the low order 32 bits being incremented??? Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Polyakov Sent: 08 July 2005 13:23 To: openssl-dev@openssl.org Subject: Re: AES CTR mode implementation > The counter increment function blindly assumes that the counter value > can be incremented across the whole 128 bits of the counter block. Correct, which is why it's called AES_ctr128_*. > If you look at (e.g.) RFC3686 or the NIST 800-38A publication, then > they both envisage a counter block that incorporates a nonce and a block counter. 800-38A essentialy says "up to impementator," doesn't it? "The standard incrementing function can apply either to an entire block or to a part of a block." > e.g. RFC 3686 specifies a counter block like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Initialization Vector (IV) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Block Counter | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > then when the low order 32 bits overflows, the IV value will be > overwritten in the current implementation. > > Shouldn't the AES CTR mode operation specify the number of bits to be > used for the block counter and keep track to ensure the no more than > 2^(block counter bits) are encrypted for this session? One can discuss additional function[s], AES_ctr_ipsec perhaps or AES_ctr_variable, which would provide for this, but it would be inappropriate to modify AES_ctr128_*. In other words it's not a matter for fixing present code, but extending functionality with new code. Is there broader interesent for ipsec-specific function than for variable? BTW I have AES_CCM_ipsec implementation pending. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
