Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of AES key as IV will leak the key #591

Open
blueben opened this issue Aug 21, 2018 · 6 comments
Open

Use of AES key as IV will leak the key #591

blueben opened this issue Aug 21, 2018 · 6 comments
Assignees
Labels

Comments

@blueben
Copy link

blueben commented Aug 21, 2018

if(!EVP_EncryptInit_ex(aes_encrypt_ctx, aes_cipher, NULL, arg_aes_key, arg_aes_key)) {

EVP_EncryptInit_ex is being called with arg_aes_key as the IV. This is a problem as an IV must be both unique (used only once) and random when used in a CBC mode (as is the case here). This means that the IV is easily recovered and because the IV is the key, it means that attackers can recover the key and decrypt any data being transported. In short, as implemented today the crypto scheme for dynomite is completely ineffective.

References:
https://en.wikipedia.org/wiki/Initialization_vector
https://defuse.ca/blog/recovering-cbc-mode-iv-chosen-ciphertext.html
http://www.cryptofails.com/post/70059594911/cakephp-using-the-iv-as-the-key
https://nsamteladze.wordpress.com/2016/05/27/initialization-vector-iv-in-aes-cbc/

@numberten
Copy link

numberten commented Oct 29, 2018

Openssl isn't appending the iv to the ciphertext for use in decryption, which is why it's required for decryption. Since the iv isn't being sent over the wire, the only side effect of making the iv equal to aes_key is that encryption is now deterministic.

Since there is no encryption oracle, an attacker isn't able to guess plaintexts either (the advantage gained by determinism).

@smukil
Copy link
Contributor

smukil commented Oct 31, 2018

@numberten You bring up a fair point, however, even though there isn't an encryption oracle, snooping traffic for long periods of time could give an attacker some insight into the data due to the determinism. It definitely would be a hard attack to carry out, but we should still fix it nonetheless.

@numberten
Copy link

@smukil

It definitely would be a hard attack to carry out, but we should still fix it nonetheless.

I agree!

I tried to keep my original comment succinct with the intention of explaining why I didn't think dynomite's crypto scheme was "completely ineffective". I'm definitely not advocating for deterministic encryption!

@blueben
Copy link
Author

blueben commented Jan 8, 2019

Fair enough. Completely ineffective is a bit hyperbolic. Still, I'm glad this is on the docket to fix.

@blueben blueben closed this as completed Jan 8, 2019
@numberten
Copy link

#618 is my proposed solution for this issue. Probably worth keeping this ticket open, or creating a new one making note of the deterministic encryption, until a fix (#618 or otherwise) is merged into a stable branch.

@ipapapa
Copy link
Contributor

ipapapa commented Jan 28, 2019

@numberten see my comments on the PR on why #618 has not moved forward. I also do not feel we should be closing this issue until it is fixed.

@ipapapa ipapapa reopened this Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants