Backups are encrypted using the wrong password

[jvalskis]

Encryption

I needed to restore my backups today and was surprised to find that my passphrase from secret_key.txt does not work. I managed to get them decrypted, but I believe the key is stored (or used) incorrectly.

The file is formatted by splitting the key into a number of lines 64 symbols each. E.g.

bXkgcGFzc3dvcmQg
aXMgbG9uZyBidXQ
gSSBvbmx5IHVzZSB
0aGUgZmlyc3QgbG
luZQ==

The backups were encrypted using only the first line bXkgcGFzc3dvcmQg as the passphrase.

Documentation

To restore the files documentation gives us the following lines:

export PASSPHRASE=$(cat your_backup_secret_key_file.txt)
sudo -E duplicity restore --force file:///path/to/copied/files /home/user-data/

What this ends up doing is setting PASSPHRASE to the last line luZQ== of the secret_key.txt file. And of course that does not work.

[jvalskis]

Looking at the code I can see that it was the intention to use only the first line of the whole file.

def get_passphrase(env):
    # Get the encryption passphrase. secret_key.txt is 2048 random
    # bits base64-encoded and with line breaks every 65 characters.
    # gpg will only take the first line of text, so sanity check that
    # that line is long enough to be a reasonable passphrase. It
    # only needs to be 43 base64-characters to match AES256's key
    # length of 32 bytes.
    backup_root = os.path.join(env["STORAGE_ROOT"], 'backup')
    with open(os.path.join(backup_root, 'secret_key.txt')) as f:
        passphrase = f.readline().strip()
    if len(passphrase) < 43: raise Exception("secret_key.txt's first line is too short!")

    return passphrase

But then why store the whole file and not the part that matters?

[JoshData]

Backwards compatibility for boxes that were created before the current way things work.