README additions #58
README additions #58
Conversation
| ### What alogorithm should I use? | ||
|
|
||
| Unless you need to maintain compatibility with an older system (or you know exactly what you're doing), | ||
| you should use "aes-256-gcm" for the mode. |
There was a problem hiding this comment.
Unfortunately, I think GCM or CTR modes require the set of IVs to be unique. There can be no overlap, basically.
The code currently generates IVs randomly if not provided. It doesn't guarantee uniqueness.
For GCM mode, perhaps we should allow options.iv to be a function where library users can provide a function that guarantees uniqueness.
Until then, CBC might be safer.
There was a problem hiding this comment.
CBC requires unique IVs, too. All modes of operation for AES to (with the possible exception of SIV which isn't available in Node anyway).
If the IVs are 16-bytes long and generated with a Cryptographically Secure Pseudo Random Number Generator (CSPRNG) then that is perfectly fine. The randomBytes function (that is used internally now) meets this requirement.
Providing a function to generate the IV would work but puts a lot of responsibility on the developer and could make mistakes more likely. Note: with SIV, I say possible because that mode is "resistant" to IV reuse but still recommends unique IVs.
| ### Should I hardcode the IV? | ||
|
|
||
| No. Don't ever do this. | ||
| It will break the encryption and is vulnerable to a "repeated nonce" attack. | ||
|
|
||
| If you don't provide an IV, the library will randomly generate a secure one for you. |
There was a problem hiding this comment.
Maybe "In practice, hardcoding an IV is not secure. See repeated nonce attack." And link to https://www.elttam.com/blog/key-recovery-attacks-on-gcm/.
|
|
||
| ### Should I hardcode the IV? | ||
|
|
||
| No. Don't ever do this. |
There was a problem hiding this comment.
Strong words... in a test case I think using the same IV is fine.
There was a problem hiding this comment.
Strong words indeed but for good reason! How about we say "No. Don't ever do this in production." ?
| @@ -179,6 +177,23 @@ class User { | |||
|
|
|||
| Queries that transform the encrypted column wont work because transformers and subscribers operate outside of the DBMS. | |||
|
|
|||
| ### What alogorithm should I use? | |||
|
|
|||
| Unless you need to maintain compatibility with an older system (or you know exactly what you're doing), | |||
There was a problem hiding this comment.
I think these algorithms have different properties that have different applications and requirements. We can give advice like "aes-256-gcm works well for encryption at rest" and point people to more information. But I don't think we should give off a tone where all of this stuff seems beyond them.
So how about this:
Which algorithm should I use?
aes-256-gcm works well for encryption at rest.
For a break down of algorithms, see https://stackoverflow.com/questions/1220751/how-to-choose-an-aes-encryption-mode-cbc-ecb-ctr-ocb-cfb.
There was a problem hiding this comment.
I have no problem in pointing people to educational resources. Having said that, its probably worth mentioning that unless you understand this stuff well that GCM is generally the best choice.
CBC does not provide authenticity and so is vulnerable to chosen ciphertext attacks.
|
Thanks @coderdan for your PR. Great work! |
Updated the README to make sure insecure code doesn't get implemented by copy-pasta.