3 ms·
Thanks 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
by higgins 5y ago
Thanks 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