0

Me and my colleagues are trying to exchange encrypted config files. Person A is able to decrypt a file encrypted-dev.enc encrypted by person B. But I can't decrypt it, and person B can't decrypt a file I send her. The error is

bad decrypt
4672347584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:610:

From reading around (for example this answer), this error refers to the algorithm openssl uses for the message digest. To fix it, people always tell you to specify the algorithm with an argument like -md md5. But our command already includes that argument.

  • Person A is on openssl 1.1.1f.
  • Person B is on openssl 1.1.1i.
  • I am on openssl 1.1.1j.

To encrypt, we're using this command:

export CONFIG_KEY='[ key ]'
openssl enc -md sha1 -aes-256-cbc -pbkdf2 -pass env:CONFIG_KEY -out ./tests/e2e/config/encrypted-dev.enc -in ./tests/e2e/config/config-dev.json

To decrypt, we're doing this:

export CONFIG_KEY='[ key ]'
openssl enc -md sha1 -aes-256-cbc -pbkdf2 -d -pass env:CONFIG_KEY -in ./tests/e2e/config/encrypted-dev.enc -out ./tests/e2e/config/config-dev.json

Has anybody else run into this situation?

And Finally
  • 5,602
  • 14
  • 70
  • 110
  • This could also be because of encoding differences between the "keys" - they are actually passwords of course, not keys. Do you maybe use non-ASCII characters? Which systems are you on? – Maarten Bodewes Aug 26 '21 at 11:51
  • Thanks! We're all on macOS, and getting the key from the same source in the same way. – And Finally Aug 26 '21 at 12:09
  • I think you were right @MaartenBodewes – this issue may have been caused by a copy of the key that missed some of the characters. We're now able to encrypt/decrypt, using the `-md md5` argument. Seems incredible that openssl's error message gives you no clue, but I suppose that's for security reasons. – And Finally Aug 26 '21 at 13:49
  • OpenSSL has never really been designed for secure encryption through the command line. It always seemed more like a example use of the cryptographic functions to me (e.g. a PBKDF with an iteration count of 1). However, in this case: there is no way to distinguish between a corrupted ciphertext or a wrong key, so it just gives a rather technical error message that the padding is invalid. You may want to use authenticated encryption instead. – Maarten Bodewes Aug 26 '21 at 14:27
  • Thanks a lot for pointing me in the right direction! – And Finally Aug 26 '21 at 15:09
  • Uh, small note: that doesn't distinguish between a wrong key or corrupted ciphertext either, but at least you get a consistent error message, for CBC decryption of bad ciphertext or key may succeed. – Maarten Bodewes Aug 26 '21 at 15:45

1 Answers1

0

To investigate your issue, add -p flag to dump the key and IV, they must be identical when ciphering and deciphering. Add -nosalt to disable salting password (with a random value) to make password to key computation constant.

$ openssl enc -p -nosalt -md sha1 -aes-256-cbc -pbkdf2 -pass env:CONFIG_KEY -out ./tests/e2e/config/encrypted-dev.enc -in ./tests/e2e/config/config-dev.json
key=27D3CEEB44142947B9ADFA4E6D7F6EB731EB6828A6CD4C49257079470599A443
iv =35E21E3684C06DB2F182D69D99BD6E9C

in your case, you will get two differents values, that's your problem.

The parameter name CONFIG_KEY is not accurate, because you are setting a password nota key, CONFIG_PASSW would be more suitable.

If your goal was to use a key (not a password), you can use this syntax

$ openssl enc -e -aes-256-cbc -nosalt -K AC7CBA91D9523EA2A9166341EC66D9DDCB14D3F6BCE33ADB59B16BE8F40AE607 -iv 208DE031141C4ACA18EA7B71B2EAA935 -in test.txt -out test.enc

$ openssl enc -d -aes-256-cbc -nosalt -K AC7CBA91D9523EA2A9166341EC66D9DDCB14D3F6BCE33ADB59B16BE8F40AE607 -iv 208DE031141C4ACA18EA7B71B2EAA935 -in test.enc
Hello world !!!
Arnaud Grandville
  • 859
  • 8
  • 10
  • Can you give a bit more info for the benefit of openssl novices Arnaud? In this context, does "dump" mean display both key and Initialization Vector (whatever that is) in output? And what's the benefit of not salting? We did notice our encrypted texts began with `Salted__`, but weren't sure of the significance, since we'd not specified a salt. – And Finally Aug 27 '21 at 15:53