>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: owner-openssl-dev@openssl.org [mailtowner-openssl-dev@openssl.org]
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 majordomo@openssl.org



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