Should the cipher-object be created with an IV?

[letharion]

I'll start by saying I'm not a crypto expert by any means.

However, it was pointed out on HN that the encrypt function doesn't use an IV when initializing the cipher object, and the node documention explicitly says

"In line with OpenSSL's recommendation to use pbkdf2 instead of EVP_BytesToKey it is recommended that developers derive a key and IV on their own using crypto.pbkdf2() and to use crypto.createCipheriv() to create the Cipher object."

Since the official docs appears to recommend against crypto.createCipher() I figured it was worth bringing up.

[iangcarroll]

To be clear: if two ciphertexts use the same IV across ciphertexts with CTR, you basically have no encryption, as C1^C2=P1^P2, where Cs are the ciphertexts and Ps are the plaintexts.

[gradientsky]

IV doesn't have to be secure, but it has to be securely random on every re-encryption.

[stouset]

@sgdread Technically for CTR mode, it only needs to be unique and not necessarily random or unpredictable — it's a nonce, not an IV.

[HainaLi]

This is an important implementation issue! I'm currently traveling and will try to push a fix out asap.

[HainaLi]

Thanks for your input. The issue is fixed with ef8bc9a.

We also changed the block cipher mode of operation to GCM. The encryption (and decryption code) are moved to utils.js line 19.