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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
