Hi,
RFC 3686 is specific to IPSEC and using AES-CTR as the algorithm for
their encapsulated security payload. To me, the RFC indicates a 32 bit
counter (when all they really need is 28 bits) to handle the IPV6
jumbogram.
>From the RFC 3686:
.
.
.
Block Counter
The block counter field is the least significant 32 bits of the
counter block. The block counter begins with the value of one,
and it is incremented to generate subsequent portions of the key
stream. The block counter is a 32-bit big-endian integer value.
Using the encryption process described in section 2.1, this
construction permits each packet to consist of up to:
(2^32)-1 blocks = 4,294,967,295 blocks
= 68,719,476,720 octets
Housley Standards Track [Page 7]
RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
This construction can produce enough key stream for each packet
sufficient to handle any IPv6 jumbogram [JUMBO].
.
.
.
Housley Standards Track [Page 15]
RFC 3686 Using AES Counter Mode With IPsec ESP January 2004
.
.
.
A 28-bit block counter value is sufficient for the generation of a
key stream to encrypt the largest possible IPv6 jumbogram [JUMBO];
however, a 32-bit field is used. This size is convenient for both
hardware and software implementations.
Paul
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David C. Partridge
Sent: Friday, July 08, 2005 10:13 AM
To: openssl-dev@openssl.org
Subject: RE: AES CTR mode implementation
>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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
