Unsafe encryption & decryption

[veeti]

Using a cryptographically random and unique initialization vector for each message is absolutely essential. The library should not let users encrypt without one: preferably, don't let the user choose at all and generate a new IV for them every time.

In addition, encrypted messages are not authenticated at all.

The encryption & decryption scheme provided by this library is very dangerous and should not be released in this state. Please take a look at something like Fernet on how to implement this securely, and only provide a higher level API to users.

[dougwilson]

Hi @veeti, I 100% agree with your statement, thus why this module has not been published to npm yet. This module was adopted by crypto-utils to give it life, but there hasn't been a lot of time. I think it would be most helpful if you could provide pull requests to fix the behavior, or at least outline the specific changes you want. This issue doesn't really help explain any more than how I already feel about the current code, so I'm not sure what you are specifically looking for.

You'll find the existing published version does not have any encypt/decrypt functionality.

[veeti]

Hey @dougwilson, I can certainly work on a pull request. Let's make sure we're on the same page. Here's what I would do:

• First, remove the capability to change the underlying cipher at all. Every cipher and mode has its own requirements for safe usage, so it's not realistic to provide this functionality. AES-256-CBC is a sane default as long as it is properly used. (AES-GCM would be ideal, but I don't think older versions of OpenSSL or Node support it).
• Add documentation for secure key generation (for example, a command-line oneliner).
• Run all input key material through PBKDF2. This ensures that whatever the user provides as keys, we get proper 32 byte keys out of them. Since the user's inputs are expected to be already cryptographically secure and not weak passwords, a practically instant iteration count (1000?) and static salt are sufficient. This is like using PBKDF2 as a standard library alternative to something like HKDF.
• Last, rewrite the encryption and decryption logic by adding random IV generation and ciphertext authentication.

Let me know what you think.

[jonathanong]

preferably, don't let the user choose at all and generate a new IV for them every time.

AES-256-CBC is a sane default as long as it is properly used. (AES-GCM would be ideal, but I don't think older versions of OpenSSL or Node support it).

these sound good to me. i was struggling with understanding how that all works which is why i was looking for reviewers. making them optional also made the API more convoluted. few options is better.

[jonathanong]

@veeti would you like to make a PR?

[jonathanong]

https://github.com/csquared/fernet.js looks good to me, except it has all this fluff for browser usage that wouldn't be applicable to us and has all these global options that are no bueno

[veeti]

Sorry, I forgot all about this. I could work on a PR soon.

[frederikhors]

Any news on this after 2+ years?

[dougwilson]

The encryption and decryption was never published to npm and does not exist in the code base.