I've been looking at the AES CTR mode implementation in 0.9.7

The counter increment function blindly assumes that the counter value can be
incremented across the whole 128 bits of the counter block.

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.

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?

I've not had any chance to look at the 0.9.8 code yet, so apologies if this
is fixed in the new release.

Regards,
David C. Partridge
Technical Products Director
Primeur Security Services
Tel: +44 (0)1926 511058
Mobile: +44 (0)7713 880197


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org