aes-ctr example needs to create a different IV for each encryption

[scriby]

Using a fixed secret will cause it to use the same IV every time. It's very important to use a different IV for every encryption, especially when using aes-ctr.

[jjarmoc]

👍 @scriby I just came across this code via a blogpost, and had exactly the same thought. Initially I thought maybe the nonce was initialized internally in the AES-CTR function, but it seems this is just a wrapper around OpenSSL, so that doesn't appear to be the case.

You probably want the three-argument crypto.createCipheriv('aes-256-ctr' key, iv) call after generating a random value for iv via crypto.randomBytes() It's still true that 'random' will eventually collide, but unless we can allocate the nonce by incrementing it with each encryption (and be confident we preserve that state) this can extend the nonce collision rate beyond the point where it can be practically exploited in many applications.

[scriby]

The IV is 128 bits which is considered large enough to not worry about collisions. Unless you are generating trillions and trillions of IV :0

On Apr 20, 2016, at 5:01 AM, Jeff Jarmoc notifications@github.com wrote:

👍 @scriby I just came across this code via a blogpost, and had exactly the same thought. Initially I thought maybe the nonce was initialized internally in the AES-CTR function, but it seems this is just a wrapper around OpenSSL, so that doesn't appear to be the case.

You probably want the three-argument crypto.createCipheriv('aes-256-ctr' key, iv) call after generating a random value for iv via crypto.randomBytes() It's still true that 'random' will eventually collide, but unless we can allocate the nonce by incrementing it with each encryption (and be confident we preserve that state) this can extend the nonce collision rate beyond the point where it can be practically exploited in many applications.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[jjarmoc]

@scriby well, for CTR the IV bits are divided between nonce and counter, and it's the nonce bits that ensure different keystreams. It's most likely 96 bits of nonce and 32 bits of counter. This means we can expect a duplicate nonce in an average of 2^48 encryptions. Still a large number, to be sure, and likely beyond an adversary's reach in most applications but significantly fewer than 128 bits.

[owlstead]

By now it should be clear that the examples are completely insecure because the nonce will be zero as well, source