intra2net / paperbackup

Create a pdf with barcodes to backup text files on paper. Designed to backup ASCII-armored GnuPG and SSH key files and ciphertext.
MIT License
135 stars 17 forks source link

Scripts to paperbackup arbitrary input data with symmetric encryption #8

Open fedorkotov opened 6 years ago

fedorkotov commented 6 years ago

Added script to do symmetric encryption and base64 encoding on input files before passing them to paperbackup.py. And another script to decode and decrypt resulting backups.

intra2net commented 6 years ago

Thank you for working on paperbackup. I like the idea to ease the use of symmetric encryption.

Some observations about the patch:

Is this the same as on your machine?

You could also check if gpg2 is available in the path and call it, if not fall back to calling gpg.

fedorkotov commented 6 years ago

Thank you for feedback

why do you need the extra call to base64? Can't you use the --armor option to gpg?

I opted for this extra call to avoid wasting valuable bytes for "-----BEGIN PGP MESSAGE-----" and "-----END PGP MESSAGE-----" headers added by gpg --armor option. With information density this low it matters IMHO.

you call "gpg". At least on my machine this is the old gpg version 1.4 which you don't want to use unless for compatibility reasons. "gpg2" would be a more modern gpg. You could also check if gpg2 is available in the path and call it, if not fall back to calling gpg.

I used gpg because it was already installed on my Ubuntu 16.04 and has less dependencies then gpg2. Default AES symmetric algorithm was good enough for my use case. Anyone who specifically targets paper backup of my passwords stored in my home will probably apply rubber-hose cryptoanalysis to extract encryption key from me. So encryption strength does not matter much. I just don't want to store it in plain text in case the backup will find it's way to waste bin unshredded for some reason.

But I agree that in general gpg2 would be better if it's available and I probably should also add option for encryption algorithm selection. I will do it on weekend.

what happens if the call to gpg (or gpg2) fails, because the file does not exist, the user didn't enter a password and so on? Shouldn't the script detect this and abort with an error code? It shouldn't try to create pdfs of empty files.

I agree. Will fix

I'm unsure about the name "gpg-paperbackup.sh": it doesn't convey that you are using symmectric encryption, from the name alone it could also use your regular keystore or do some other fancy gpg operation. Maybe "paperbackup-symmetric.sh" and "paperrestore-symmetric.sh"?

I agree. Your variant is better.

would it be possible to also allow piping the input file to gpg-paperbackup.sh? If yes, this would be a nice extension. Or would it conflict with the password prompt?

I'll investigate that. And add this option if possible in next commit.

Please don't mix any "/usr/bin/bash" vs. "/bin/bash" changes into the checkin. This is a separate issue, requiring a separate issue/pull. Probably using env would be the most compatible way.

I noticed that in paperrestore.sh you used "/bin/bash" and "/usr/bin/bash" in "paperbackup-verify.sh" I have only "/bin/bash" out of the box on my Ubuntu 16.04 so I chose the variant that works for me. But I agree that it is a separate issue. I will leave your scripts "as is" and change shebang to "#!/usr/bin/env bash" in my added scripts

I'll try to prepare next commit at next weekends.

fedorkotov commented 6 years ago

Hope these changes address your concerns. Please let me know if you think something else should be changed or if I missed something.

intra2net commented 6 years ago

Thank you for adapting your patches to my suggestions. Everything looking good now except two small bits:

But on the other hand, the "-----BEGIN PGP MESSAGE-----" is implicit documentation how to decode it. Let's say in a decade or more, someone needs to decode the message, knows the password, but a lot of context around it is lost or outdated, github turned evil or was switched off, and so on. With the text "-----BEGIN PGP MESSAGE-----" in the plaintext section, he instantly know that he needs some pgp compatible program to decode this. The pure base64 doesn't convey this.