Stephen Sprunk wrote:
Thus spake "David Maurus" <[EMAIL PROTECTED]>Where did you find that? Is it possible that you've got an older version?
I assume that 'number /nonce/' should mean the result of the
concatenated parts of the IV.
No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers to the top 64 bits and 'ctr' refers to the lower 64 bits.
In Nist's sp800-38a, available at http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
the corresponding paragraph concerning counter mode with nonces reads (page 19):
"A second approach to satisfying the uniqueness property across messages is to assign to each
message a unique string of b/2 bits (rounding up, if b is odd), in other words, a message nonce,
and to incorporate the message nonce into every counter block for the message. The leading b/2
bits (rounding up, if b is odd) of each counter block would be the message nonce, and the
standard incrementing function would be applied to the remaining m bits to provide an index to
the counter blocks for the message. Thus, if N is the message nonce for a given message, then
the jth counter block is given by Tj = N | [j]m, for j = 1…n. The number of blocks, n, in any
message must satisfy n < 2m. A procedure should be established to ensure the uniqueness of the
message nonces."
In the middle of this quotation you'll find the sentence: 'The leading b/2 bits (rounding up, if b is odd) of each counter block would be the message nonce, and the standard incrementing function would be applied to the remaining m bits to provide an index to the counter blocks for the message".
I think this is clear on the fact that e.g. with a 128 bit 'counter block' / IV, you'd use the leading 64 bits for the nonce (I'd interpret 'leading' as the Most Significant Bits, if the bits would represent a number), while the remaining 64 bits of the 'counter block' / IV are the bits that are actually counting up, i.e. get incremented.
As I pointed out (I think), if you let the user provide an IV, let's say a 128 bit IV, and make clear in the documentation that the best way to use it would be to fill the highest 64 bit with a unique nonce, and clear the lowest 64 bits, as they will be used as a counter, there will be no problem. We could word the usage instructions even more general, saying that the lowest bits get used as counter, and that no more blocks should be encrypted with the same key and that counter, as the bits used as counter allow.Unfortunately, the current API has no way to report "no more encryption possible, you must rekey".
Given this limitation, two silent failure modes are possible: either wrap and reuse ctr values, or don't wrap and use nonce values the user didn't specify.
You're right. While as Lee Dilkie pointed out, the IPSec message format will not allow that this 32 bit counter will overflow, I'd like to refrain from my previous recommendation to 'follow the IPSec draft as close as possible' in this issue, since 32 bit are obiously not enough for SSL.32bit counters can wrap in under a minute; IPsec clearly has a pressing problem, but I'm not sure how to code to support both without giving up and making the ctr-increment function a user parameter.
Again, in the version of the NIST document I've linked to above, I can't find a statment that the nonce is to be incremented. I can only find the requirement that the nonce must be unique for the encryption key.Per the NIST spec, the next nonce chosen will be the old nonce plus one, so the user's choice will always be "unlucky".
Of course I'd be glad if we could check the counter and throw an exception when it overflows, but the interface for the low level crypto routines doesn't seem to accommodate that. All functions return a 'void', e.g. nothing. I assume we cannot change that. (without breaking other parts).The easiest way to go about it would be to increment the user supplied
IV by 1 for each encrypted block, and leave it to the user of this
function to make sure that no overflow in the counter can occur. This
obligation to the programmer should be written somewhere in big letters
;-) (i.e. DON'T USE COUNTER MODE TO ENCRYPT MORE
THAN 2**32 [or 2**64, depending on the counter size] BLOCKS
WITH THE SAME KEY!). Higher level routines, i.e. the SSL BIO,
should avoid counter overflows automatically for the user by initiating a
rehandshake.
While this option is tempting, and the user does have access to the counter at all times to check for impending overflow, experience shows that programmers ignore such warnings more often than not.
Best Regards, - David
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
