> 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 majordomo@openssl.org