"bad decrypt" when there are multiple encrypted files

Environments Linux
1

Builds that pass variables in an encrypted file have started failing without any changes to the repo. I’ve seen this for both xenial py2 and bionic py3 builds. Any idea what might be going on?

https://travis-ci.org/Gluejar/regluit/builds/654972119

2

This is quite curious. The first failure occurred 6 days ago, and failures continue to this day, but there have been 2 successes since the first failure https://travis-ci.org/Gluejar/regluit/builds/653163733 https://travis-ci.org/Gluejar/regluit/builds/654668678. I cannot reason how this might happen.

If you restart one of these successes, does it fail now?

3

Have tried restarting the build, just tried this one again https://travis-ci.org/Gluejar/regluit/builds/654746203 master branch has not been touched in 18 days!

4

Successes are on 18.04.3, failures are on 16.04.6 and 18.04.4.

Googling suggests that this happens if there is a breaking change between OpenSSL versions used to encrypt and the one used to decrypt:

I must also note that aes-256-cbc doesn’t seem to be a documented openssl subcommand.

5

Hmm. That is rather disconcerting. We’ll look into it more. Thanks for bringing this to our attention.

It is. Otherwise openssl would not tell you it’s a “bad decrypt”.

OpenSSL command help text 
$ openssl version
OpenSSL 1.1.1d  10 Sep 2019
$ openssl aes-256-cbc --help
Usage: aes-256-cbc [options]
Valid options are:
 -help               Display this summary
 -ciphers            List ciphers
 -in infile          Input file
 -out outfile        Output file
 -pass val           Passphrase source
 -e                  Encrypt
 -d                  Decrypt
 -p                  Print the iv/key
 -P                  Print the iv/key and exit
 -v                  Verbose output
 -nopad              Disable standard block padding
 -salt               Use salt in the KDF (default)
 -nosalt             Do not use salt in the KDF
 -debug              Print debug info
 -a                  Base64 encode/decode, depending on encryption flag
 -base64             Same as option -a
 -A                  Used with -[base64|a] to specify base64 buffer as a single line
 -bufsize val        Buffer size
 -k val              Passphrase
 -kfile infile       Read passphrase from file
 -K val              Raw key, in hex
 -S val              Salt, in hex
 -iv val             IV in hex
 -md val             Use specified digest to create a key from the passphrase
 -iter +int          Specify the iteration count and force use of PBKDF2
 -pbkdf2             Use password-based key derivation function 2
 -none               Don't encrypt
 -*                  Any supported cipher
 -rand val           Load the file(s) into the random number generator
 -writerand outfile  Write random data to the specified file
 -engine val         Use engine, possibly a hardware device
1 Like
6

If it helps, openssl on the encrypt side is “OpenSSL 1.0.2q 20 Nov 2018”

The encrypted file on the Master branch has been unchanged in since Apr 10, 2019.

7

Is it possible to re-encrypt the file with a newer version of OpenSSL?

8

openssl installs on the mac break things, I’ve found. I’ll try this, but it would be disturbing if version updates make file un-decryptable!

9

Encrypting another file later will overwrite the secure variable, rendering the old file unusable.

does this mean that I can’t have different encrypted files on two branches?

1 Like
10

OK, that’s the cause! I can get around the problem for now by using the same encrypted file in both branches. Please escalate the PR.

1 Like
11

OK, maybe not. Now I have the exact same encrypted file on two different branches. it’s passing on the py2/xenial branch and failing on the py3/bionic branch.

12

Has been fixed as per `encrypt-file` overwrites previous secure keys when invoked from same working folder and causes file decryption failures when used with multiple files · Issue #627 · travis-ci/travis.rb · GitHub

BanzaiMan commented on Apr 7

I believe we pushed a fix recently #678.

13

As per Custom deployment - Problem with SFTP key and cURL: "curl failed to verify the legitimacy of the server" - #13 by aleks-rodriguez, it looks like this problem resurfaces if one is using the same decryption key variables multiple times:

$ openssl aes-zss-cbc -K Sencrypted_9886as3a028f_key -1v Sencrypted_9806a53a028f_1v -in ssh-pair.enc -out ssh-pair -d
<...>
$ openssl aes-zss-cbc -K Sencrypted_9886asaad28f_key -iv Sencrypted_9806a533d28f_iv -in id_rsa.enc -out id_rsa -d
bad decrypt

In this case, make sure to use the exact command, including variable names, that travis encrypt-file gave you.
(And if travis encrypt-file actually gave you identical variable names, this means you’re using a very outdated version of the travis gem – which you should have received a warning about.)