This is a discussion on Re: AES CTR mode implementation - Openssl ; > 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 ...
> 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 email@example.com
Automated List Manager firstname.lastname@example.org