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

Scripts to paperbackup arbitrary input data with symmetric encryption #8

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

fedorkotov
Copy link

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.

…files before passing them to papaerbackup. And another script to decode and decrypt resulting backups.
@intra2net
Copy link
Collaborator

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

Some observations about the patch:

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

  • 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.

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.

  • 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'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"? But restore isn't limited to symmetric decryption, it would work for all kinds of encryption that gpg understands. So "paperrestore-gpg.sh" would also be viable.

  • 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?

  • 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.

@fedorkotov
Copy link
Author

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
Copy link
Author

fedorkotov commented Jul 8, 2018

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

@intra2net
Copy link
Collaborator

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

  • please add a short section to the README.md explaining how to use the symmectric scripts

  • I'm still not convinced that using base64 is a better solution than using the --armor option. I tried both and compared the size. Yes, --armor is a bit more verbose with it's "-----BEGIN PGP MESSAGE-----" stuff, so I see your point. But still is just a few bytes, much less than one qr code block.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants