You are not logged in.
Hi fellow Arch users,
I wanted to securely store my GPG secret key on a no-tech medium, aka paper.
Found this program called "paperkey" and associated arch wiki page.
My problem is I can't get the full encode/decode flow to work properly.
I followed the instruction for storing the paperkey in a QR code for a painless recovery in case of distaster. Or so I thought, it seems the pain has to be invested up-front! Followed the commands to a T, and checked out the man pages for paperkey, qrencode and zbarimg and tried all possible combinations to get the data to encode/decode properly.
Paperkey properly does its job properly, it's qrencode and/or zbarimg that are causing the problem. I tested this with a simple randomly generated binary. Zbarimg does not correctly decode the binary data that qrencode encodes. Diffing the input and output of the encode/decode flow tells me the files are not same.
For reference, after fiddling with both programs and reading about QR codes, I ultimately...
- ...used qrencode 4.1.1 with these options: --8bit
- ...used zbarimg 0.23.1 with these options: --oneshot --raw -Sqr.binary --quiet
I found out about the -Sqr.binary options from a recently active github pull request that is merged and included in my installed version of zbarimg.
Somehow the data encoded in the QR code gets garbled before/after decoding.
I tried shimming in base64 encoding/decoding (and using regular case-sensitive QR encoding) to alleviate possible issues with binary encoding, but to no avail.
Do any of you have experience with this? Or maybe you know of an alternative user-friendly way of storing a secret key?
Last edited by toond (2021-02-11 22:35:08)
Offline
I tried shimming in base64 encoding/decoding (and using regular case-sensitive QR encoding) to alleviate possible issues with binary encoding, but to no avail.
I was going to suggest the same thing until I reached that part. The base64 encoding should ensure that it's not an encoding issue with random binary data. Do you have a second QR code scanner to check the output from qrencode (e.g. a smartphone)? That would at least let you identify where the error occurs. Have you checked that scanning the same printed code always yields the same result to check that it's not an image problem (QR codes are supposed to have a configurable level of redundancy but it's better to rule the the read issue just in case).
edit: Ignore the last part. I had the intended workflow in mind so I didn't consider that you're probably reading the generated images directly for testing.
Last edited by Xyne (2021-02-05 23:38:05)
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Thanks for the reply Xyne.
Tried the android app "Binary eye", it produces the exact same output as zbarimg does.
But both are different from the original data fed via standard input to qrencode.
For fun I made a small 32x32 obscene image in GIMP to serve as binary data, let's call it cnb.png.
I then ran:
base64 cnb.png > regularand
base64 cnb.png | qrencode -o qr.png && zbarimg -1 --raw -q qr.png > qr(no special binary options because base64 output is plain text)
then
diff regular qrand guess what: the regular and qr file are the same!
But when I instead feed paperkey output into the same flow, both are different!
Commands for reference:
gpg --export-secret-key snip@email.com | paperkey --output-type raw | base64 > key-regulargpg --export-secret-key snip@email.com | paperkey --output-type raw | base64 | qrencode -o key-qr.png && zbarimg -1 --raw -q key-qr.png > key-qrdiff key-regular key-qrCan anyone replicate this behaviour?
Offline
It does work with -Sbinary instead of -Sqr.binary, alternatively tell zbarimg to decode only 1 image (--oneshot / -1) Otherwise zbarimg appends a newline character (0x0A) after reading the qrcode. I do not know, why oneshot did not work for you.
mkcd /tmp/test
head -c 2048 /dev/random >rand
qrencode --8bit -otest.png <rand
zbarimg --quiet -Sqr.binary --raw test.png >qrbinary-auto
zbarimg --quiet -Sbinary --raw test.png >binary-auto
zbarimg -1 --quiet -Sqr.binary --raw test.png >qrbinary
zbarimg -1 --quiet -Sbinary --raw test.png >binary
diff rand qrbinary-auto
diff rand qrbinary
diff rand binary-auto
diff rand binaryEdit: With your base64 example, there should be an additional newline at the end, but that is irrelevant and should be ignored when decoding it.
Edit2: The output of paperkey seems to be different each time you run it...
Edit3: The key export differs to to salted passwords: https://security.stackexchange.com/ques … -different
Last edited by progandy (2021-02-06 08:24:38)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Thanks for the helpful insight progandy.
Got it working without changing anything to the approach in the OP.
Due to the initial problems I ran into I kept just verifying by diffing, which is a dumb approach when salting is involved.
There is no difference between -Sqr.binary and -Sbinary, but -Sbinary does work fine indeed.
One zbarimg option that was necessary in my case that isn't mentioned on the wiki page is -q. Without it zbarimg outputs a bunch of "garbage" text after the binary data. No idea why it does that.
The final working approach:
Creating secret paperkey QR code
gpg --export-secret-key ur@email.com | paperkey --output-type raw | qrencode -8 -o secret-key.qr.pngYou will need access to your public key when extracting the paperkey, use
gpg --export ur@email.com > pubkeyExtracting paperkey QR code
zbarimg -1 --raw -q key-qr.png | paperkey --pubring pubkey | gpg --importOffline
Thanks for posting a follow-up with a solution. Please edit the first post to mark the thread as solved by prepending "[SOLVED]" to the title.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline