Thierry Boivin <[EMAIL PROTECTED]> said:
Thierry.Boivin> My understanding of this one is (in a practical perspective) is : Thierry.Boivin> calling programs maintain a 64 bit long nonce counter.
This is not correct - to quote from the (btw excellent) new book from Bruce Schneier and Neils Fergusson ('Practical Cryptography'), Page 75: 'CTR [Counter Mode] uses a remarkably simple method to generate the key stream. It concatenates the nonce with the counter value, and encrypts it to form a single block of the key stream. This requires that the counter and the nonce fit in a single block, but with the modern 128-bit block sizes, this is rarely a problem. Oviously, the nonce must be smaller than a single block, as there needs to be room for the counter value i. A typical setup might use a 48-bit message number, 16 bits of additional nonce data, and 64 bits for the counter i. This limits the system to encrypting 2**48 different messages using a single key, and limits eacht message to 2**68 bytes'
So apparently, the trick would be to leave the nonce untouched in the higher 64 bits, and increment the 64 lower bits. Instead of overflowing to bit 65 after 2**64 message blocks, the sensible option would be to stop the encryption with this key, and choose a new one. If we would continue counting despite the overflow into the nonce, we would risk to use (or better: have no mechanism in place to avoid using) the same key with the same 128 bit nonce/counter value twice, which would generate the same cipher output block again, which would mean that we would XOR different parts of the plain text with the same cipher bits, opening an opportunity for attack (albeit a very small one).
Richard Levitte - VMS Whacker wrote:
Well, incrementing by 2**64 would only be reasonable if the nonce would be in the lower 64 bits of the 128 bit nonce/counter value.And when should the increment by 2^64 occur? Is that something that the application should make sure happens with some kind of call to the currently non-existing functino AES_incr_ctr() (perhaps done in EVP_EncryptFinal())?
If everyone can agree on such an interpretation, I have no problems changing it, as long as it also makes the implement crunch the available test vectors properly.
Best Regards, David
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
