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 richard@levitte.org
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 openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org