AES CTR mode implementation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

AES CTR mode implementation

David C. Partridge
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AES CTR mode implementation

Andy Polyakov
> 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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AES CTR mode implementation

David C. Partridge
>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: [hidden email] [mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: 08 July 2005 13:23
To: [hidden email]
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                       [hidden email]
Automated List Manager                           [hidden email]



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AES CTR mode implementation

Richard Levitte - VMS Whacker
David C. Partridge writes:

> 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
> :-(

Point is, what should we do when the counter wraps to 0 (if enough blocks
have gone through or the counter was ridiculously small)?  Either way,
that's a flaw that should be taken care of at higher functional levels.

> 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???

For AES-CCM, I think it's because the length of the whole message has to be
known in advance.  I haven't read the RFC very thorougly, but I think it
indicates that they therefore consider each packet (or at least the
jumbopacket) as one message, so a whole session is a serie of cryptographic
message.  In a straightforward implementation, where the counter block is
just that, it means the counter is started over for each packet (or at least
jumbopacket).  This is not good from a security point of view, at least as
long as the same key is used over a whole session (many packets).  So I
imagine that having a bit of random data (like a unique enough nonce) in the
high parts of the counter (high enough that we don't really expect it to be
touched when incrementing the counter) is a move to counteract the effects
of CCM and the choises made with it.

Cheers,
Richard

 -----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                       http://richard.levitte.org/ 

"When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up."
                                               -- C.S. Lewis

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: AES CTR mode implementation

Mosteika, Paul Edward (OpenVMS Engineering)
In reply to this post by David C. Partridge
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: [hidden email]
[mailto:[hidden email]] On Behalf Of David C. Partridge
Sent: Friday, July 08, 2005 10:13 AM
To: [hidden email]
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: [hidden email]
[mailto:[hidden email]]
On Behalf Of Andy Polyakov
Sent: 08 July 2005 13:23
To: [hidden email]
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                       [hidden email]
Automated List Manager                           [hidden email]



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]