3 ms·
I might not have properly understood this tool, but is the encryption key and iv getting reused? If so, it's usually quite unsafe to reuse IVs (but consult a cr
by amenghra 5y ago
I might not have properly understood this tool, but is the encryption key and iv getting reused? If so, it's usually quite unsafe to reuse IVs (but consult a cryptographer, YMMV). Feels weird to stuff the IV with the key, it should live with the ciphertext.
(I only glanced at the code for a few minutes, so I could be wrong: https://github.com/higgins/privatize/blob/0.1.1/index.js#L73 https://github.com/higgins/privatize/blob/0.1.1/index.js#L73)
- higgins 5y agoThanks for taking a look! Yeah, I should cleanup the wording in here a bit: The IV is a sha1 hmac of the content to be encrypted. The 16B that are stored with the key is used to initialize the sha1 hmac: https://github.com/higgins/privatize/blob/0.1.1/index.js#L20-L26 https://github.com/higgins/privatize/blob/0.1.1/index.js#L20...
- deathanatos 5y agoGiven that you store the IV alongside the ciphertext anyways, I'm not seeing what advantage this has over just choosing the IV at random.
- re 5y agoThis appears to be a design decision borrowed/inherited from git-crypt: https://github.com/AGWA/git-crypt#security https://github.com/AGWA/git-crypt#security The gain is that encrypted output is deterministic (which git seems to require), with the trade-off of leaking some information (particularly that multiple encrypted ciphertexts are identical). I'm not really a crypto expert, but it seems like a better alternative might be to use AES-GCM-SIV. It is designed to allow for nonce reuse, and has the advantage of being authenticated encryption. https://en.wikipedia.org/wiki/AES-GCM-SIV https://en.wikipedia.org/wiki/AES-GCM-SIV