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 protected]
Automated List Manager [EMAIL PROTECTED]
