Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Philihp Busby via Gnupg-users]

A: Take a look at Paperkey, https://wiki.archlinux.org/index.php/Paperkey; I 
think it serves this need well. Not to diminish your work, good job! It's 
probably a good thing to have diversity in implementations, so we don't get 
stuck with the only thing being written in OCaml.

B: I'm not well versed in Python, but have you tried `pip install qrencode`?

C: If you're using an rsa4096 key, extracting just the secret key with paperkey 
will just barely fit in a QR code, and if you have subkeys then just forget it 
with "export-minimal". This, to me, is a good reason to migrate to an ed25519 
key which is a deci-order of magnitude smaller (e.g. 
https://philihp.com/assets/id_ed25519.png)

On 2020-09-14T08:16:19-0400 bexnews--- via Gnupg-users  
wrote 7.3K bytes:

> Hello Friends,
> 
> Ok I am no coder so I am trying to bungle my way thru setting up
> paperbackup.py.
> 
> My goal was to be able to print out a paper encrypted backup of a strong
> key that I can use to encrypt data or other keys. I tried the Windows
> Paperbackup from OllyDbg but it is older, on Windows (I'm on Linux atm) and
> was having a hard time getting the roundtrip to work with my printer and
> scanner. Paperbackup.py looked like a smart idea and I like the redundancy
> of the QR code and text string outputs. I tried the usage instructions
> 
> 1. the first issue was I think specifically you need to prefix
> "paperbackup.py" with "python" correct?
> 2. second issue was when I do #1 I get
> 
> > Traceback (most recent call last):
> >   File "paperbackup.py", line 35, in 
> > import qrencode
> > ImportError: No module named qrencode
> >
> 
> 3. I may be failing to install all the dependencies properly. I did  "sudo
> apt install qrencode" and seems installed (qrencode version 3.4.4 Copyright
> (C) 2006-2012 Kentaro Fukuchi), but no change in the ImportError in #2. Is
> there some other way to "hook" qrencode into paperbackup.py? I tried
> putting it all into the same folder but it doesn't seem to help.
> 
> danke schoen!
> - bexnews
> 
> > Announcing paperbackup.py to backup keys as QR codes on paper *Gerd v.
> > Egidy* gerd.von.egidy at intra2net.com
> > 
> > *Tue Feb 21 15:34:17 CET 2017*
> >
> >- Previous message (by thread): Problems with cert validation via CRL
> >
> >- Next message (by thread): Announcing paperbackup.py to backup keys
> >as QR codes on paper
> >
> >- *Messages sorted by:* [ date ]
> >
> > 
> >  [
> >thread ]
> >
> > 
> >  [
> >subject ]
> >
> > 
> >  [
> >author ]
> >
> > 
> >
> > --
> >
> > Hi,
> >
> > I'd like to announce a program I wrote to backup GnuPG and SSH keys as
> > qrcodes on paper:
> >
> > paperbackup.py https://github.com/intra2net/paperbackup
> >
> > This is designed as fallback if all your regular backups failed to restore 
> > or
> > were lost.
> >
> > Usage is like this:
> >
> > gpg2 --armor --export "User Name" >key.asc
> > gpg2 --armor --export-secret-key "User Name" >>key.asc
> > paperbackup.py key.asc
> > paperrestore.sh key.asc.pdf | diff key.asc -
> > lpr key.asc.pdf
> >
> > You'll find all the details, reasoning and examples in the README.
> >
> > Kind regards,
> >
> > Gerd
> >
> >
> >
> >

> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Stefan Claas]

Stefan Claas wrote:

> Hi,
> 
> while I can't help you with your issue, I like to suggest to take a look
> at Fraunhofer SIT's modern JAB-Code, which compiles nicely under Linux,
> Windows and macOS. It has also the advantage that it can carry much more
> data than QR code. The color barcode withstands also ugly Facebook .jpeg
> compression, in case one needs to sign large messages, with GnuPG, on
> 'social' media sites.
> 
> https://github.com/jabcode/jabcode

The other option GnuPG users have is to memorize the passphrase and
re-generate the private key from the passphrase, thus avoiding paper
loss etc.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Karl Auer]

On Mon, 2020-09-14 at 08:16 -0400, bexnews--- via Gnupg-users wrote:
> import qrencode
> ImportError: No module named qrencode

You may need something like the python3-qrencode package.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users]

Additionally, you can install paperkey from the Debian repos, which might do 
something similar?

HTH!

- Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Pronouns: he/him/his

14/09/20 14:07 ನಲ್ಲಿ, ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users  
ಬರೆದರು:
> You'll have to install python3-qrencode, not qrencode. All of the 
> dependencies should by in the form of python3- (or if that's not 
> available, install it through pip3).
> 
> Hope that helps!
> 
> - Chiraag
> --
> ಚಿರಾಗ್ ನಟರಾಜ್
> Pronouns: he/him/his
> 
> 14/09/20 08:16 ನಲ್ಲಿ, bexnews--- via Gnupg-users  
> ಬರೆದರು:
> > Hello Friends,
> >
> > Ok I am no coder so I am trying to bungle my way thru setting up
> > paperbackup.py.
> >
> > My goal was to be able to print out a paper encrypted backup of a strong key
> > that I can use to encrypt data or other keys. I tried the Windows 
> > Paperbackup
> > from OllyDbg but it is older, on Windows (I'm on Linux atm) and was having a
> > hard time getting the roundtrip to work with my printer and scanner.
> > Paperbackup.py looked like a smart idea and I like the redundancy of the QR
> > code and text string outputs. I tried the usage instructions
> >
> > 1. the first issue was I think specifically you need to prefix 
> > "paperbackup.py"
> > with "python" correct?
> > 2. second issue was when I do #1 I get
> >
> > Traceback (most recent call last):
> >   File "paperbackup.py", line 35, in 
> >     import qrencode
> > ImportError: No module named qrencode
> >
> >
> > 3. I may be failing to install all the dependencies properly. I did  "sudo 
> > apt
> > install qrencode" and seems installed (qrencode version 3.4.4 Copyright (C)
> > 2006-2012 Kentaro Fukuchi), but no change in the ImportError in #2. Is there
> > some other way to "hook" qrencode into paperbackup.py? I tried putting it 
> > all
> > into the same folder but it doesn't seem to help.
> >
> > danke schoen!
> > - bexnews
> >
> > Announcing paperbackup.py to backup keys as QR codes on paper
> >
> > Gerd v. Egidy [1]gerd.von.egidy at intra2net.com
> > Tue Feb 21 15:34:17 CET 2017
> >   □ Previous message (by thread): [2]Problems with cert validation via 
> > CRL
> >   □ Next message (by thread): [3]Announcing paperbackup.py to backup 
> > keys
> > as QR codes on paper
> >   □ Messages sorted by: [4][ date ] [5][ thread ] [6][ subject ] [7][
> > author ]
> > 
> > ━━━
> >
> > Hi,
> >
> > I'd like to announce a program I wrote to backup GnuPG and SSH keys as
> > qrcodes on paper:
> >
> > paperbackup.py
> > [8]https://github.com/intra2net/paperbackup
> >
> > This is designed as fallback if all your regular backups failed to 
> > restore or
> > were lost.
> >
> > Usage is like this:
> >
> > gpg2 --armor --export "User Name" >key.asc
> > gpg2 --armor --export-secret-key "User Name" >>key.asc
> > paperbackup.py key.asc
> > paperrestore.sh key.asc.pdf | diff key.asc -
> > lpr key.asc.pdf
> >
> > You'll find all the details, reasoning and examples in the README.
> >
> > Kind regards,
> >
> > Gerd
> >
> >
> >
> >
> > References:
> >
> > [1] 
> > mailto:gnupg-users%40gnupg.org?Subject=Re%3A%20Announcing%20paperbackup.py%20to%20backup%20keys%20as%20QR%20codes%20on%20paper=%3C9664399.F7pj19RVc2%40thunder.m.i2n%3E
> > [2] https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057787.html
> > [3] https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057771.html
> > [4] 
> > https://lists.gnupg.org/pipermail/gnupg-users/2017-February/date.html#57765
> > [5] 
> > https://lists.gnupg.org/pipermail/gnupg-users/2017-February/thread.html#57765
> > [6] 
> > https://lists.gnupg.org/pipermail/gnupg-users/2017-February/subject.html#57765
> > [7] 
> > https://lists.gnupg.org/pipermail/gnupg-users/2017-February/author.html#57765
> > [8] https://github.com/intra2net/paperbackup
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users





publickey - gpg-users@chiraag.me.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Stefan Claas]

bexnews--- via Gnupg-users wrote:

Hi,

while I can't help you with your issue, I like to suggest to take a look
at Fraunhofer SIT's modern JAB-Code, which compiles nicely under Linux,
Windows and macOS. It has also the advantage that it can carry much more
data than QR code. The color barcode withstands also ugly Facebook .jpeg
compression, in case one needs to sign large messages, with GnuPG, on
'social' media sites.

https://github.com/jabcode/jabcode

Regards
Stefan

 
> Hello Friends,
> 
> Ok I am no coder so I am trying to bungle my way thru setting up
> paperbackup.py.
> 
> My goal was to be able to print out a paper encrypted backup of a strong
> key that I can use to encrypt data or other keys. I tried the Windows
> Paperbackup from OllyDbg but it is older, on Windows (I'm on Linux atm) and
> was having a hard time getting the roundtrip to work with my printer and
> scanner. Paperbackup.py looked like a smart idea and I like the redundancy
> of the QR code and text string outputs. I tried the usage instructions
> 
> 1. the first issue was I think specifically you need to prefix
> "paperbackup.py" with "python" correct?
> 2. second issue was when I do #1 I get
> 
> > Traceback (most recent call last):
> >   File "paperbackup.py", line 35, in 
> > import qrencode
> > ImportError: No module named qrencode
> >
> 
> 3. I may be failing to install all the dependencies properly. I did  "sudo
> apt install qrencode" and seems installed (qrencode version 3.4.4 Copyright
> (C) 2006-2012 Kentaro Fukuchi), but no change in the ImportError in #2. Is
> there some other way to "hook" qrencode into paperbackup.py? I tried
> putting it all into the same folder but it doesn't seem to help.
> 
> danke schoen!
> - bexnews

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users]

You'll have to install python3-qrencode, not qrencode. All of the dependencies 
should by in the form of python3- (or if that's not available, install it 
through pip3).

Hope that helps!

- Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Pronouns: he/him/his

14/09/20 08:16 ನಲ್ಲಿ, bexnews--- via Gnupg-users  ಬರೆದರು:
> Hello Friends,
> 
> Ok I am no coder so I am trying to bungle my way thru setting up
> paperbackup.py.
> 
> My goal was to be able to print out a paper encrypted backup of a strong key
> that I can use to encrypt data or other keys. I tried the Windows Paperbackup
> from OllyDbg but it is older, on Windows (I'm on Linux atm) and was having a
> hard time getting the roundtrip to work with my printer and scanner.
> Paperbackup.py looked like a smart idea and I like the redundancy of the QR
> code and text string outputs. I tried the usage instructions
> 
> 1. the first issue was I think specifically you need to prefix 
> "paperbackup.py"
> with "python" correct?
> 2. second issue was when I do #1 I get
> 
> Traceback (most recent call last):
>   File "paperbackup.py", line 35, in 
>     import qrencode
> ImportError: No module named qrencode
> 
> 
> 3. I may be failing to install all the dependencies properly. I did  "sudo apt
> install qrencode" and seems installed (qrencode version 3.4.4 Copyright (C)
> 2006-2012 Kentaro Fukuchi), but no change in the ImportError in #2. Is there
> some other way to "hook" qrencode into paperbackup.py? I tried putting it all
> into the same folder but it doesn't seem to help.
> 
> danke schoen!
> - bexnews
> 
> Announcing paperbackup.py to backup keys as QR codes on paper
> 
> Gerd v. Egidy [1]gerd.von.egidy at intra2net.com
> Tue Feb 21 15:34:17 CET 2017
>   □ Previous message (by thread): [2]Problems with cert validation via CRL
>   □ Next message (by thread): [3]Announcing paperbackup.py to backup keys
> as QR codes on paper
>   □ Messages sorted by: [4][ date ] [5][ thread ] [6][ subject ] [7][
> author ]
> 
> ━━━
>
> Hi,
> 
> I'd like to announce a program I wrote to backup GnuPG and SSH keys as
> qrcodes on paper:
> 
> paperbackup.py
> [8]https://github.com/intra2net/paperbackup
> 
> This is designed as fallback if all your regular backups failed to 
> restore or
> were lost.
> 
> Usage is like this:
> 
> gpg2 --armor --export "User Name" >key.asc
> gpg2 --armor --export-secret-key "User Name" >>key.asc
> paperbackup.py key.asc
> paperrestore.sh key.asc.pdf | diff key.asc -
> lpr key.asc.pdf
> 
> You'll find all the details, reasoning and examples in the README.
> 
> Kind regards,
> 
> Gerd
> 
> 
> 
> 
> References:
> 
> [1] 
> mailto:gnupg-users%40gnupg.org?Subject=Re%3A%20Announcing%20paperbackup.py%20to%20backup%20keys%20as%20QR%20codes%20on%20paper=%3C9664399.F7pj19RVc2%40thunder.m.i2n%3E
> [2] https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057787.html
> [3] https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057771.html
> [4] 
> https://lists.gnupg.org/pipermail/gnupg-users/2017-February/date.html#57765
> [5] 
> https://lists.gnupg.org/pipermail/gnupg-users/2017-February/thread.html#57765
> [6] 
> https://lists.gnupg.org/pipermail/gnupg-users/2017-February/subject.html#57765
> [7] 
> https://lists.gnupg.org/pipermail/gnupg-users/2017-February/author.html#57765
> [8] https://github.com/intra2net/paperbackup


publickey - gpg-users@chiraag.me.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Announcing paperbackup.py to backup keys as QR codes on paper

[bexnews--- via Gnupg-users]

Hello Friends,

Ok I am no coder so I am trying to bungle my way thru setting up
paperbackup.py.

My goal was to be able to print out a paper encrypted backup of a strong
key that I can use to encrypt data or other keys. I tried the Windows
Paperbackup from OllyDbg but it is older, on Windows (I'm on Linux atm) and
was having a hard time getting the roundtrip to work with my printer and
scanner. Paperbackup.py looked like a smart idea and I like the redundancy
of the QR code and text string outputs. I tried the usage instructions

1. the first issue was I think specifically you need to prefix
"paperbackup.py" with "python" correct?
2. second issue was when I do #1 I get

> Traceback (most recent call last):
>   File "paperbackup.py", line 35, in 
> import qrencode
> ImportError: No module named qrencode
>

3. I may be failing to install all the dependencies properly. I did  "sudo
apt install qrencode" and seems installed (qrencode version 3.4.4 Copyright
(C) 2006-2012 Kentaro Fukuchi), but no change in the ImportError in #2. Is
there some other way to "hook" qrencode into paperbackup.py? I tried
putting it all into the same folder but it doesn't seem to help.

danke schoen!
- bexnews

> Announcing paperbackup.py to backup keys as QR codes on paper *Gerd v.
> Egidy* gerd.von.egidy at intra2net.com
> 
> *Tue Feb 21 15:34:17 CET 2017*
>
>- Previous message (by thread): Problems with cert validation via CRL
>
>- Next message (by thread): Announcing paperbackup.py to backup keys
>as QR codes on paper
>
>- *Messages sorted by:* [ date ]
>
>  
> [
>thread ]
>
> 
>  [
>subject ]
>
> 
>  [
>author ]
>
> 
>
> --
>
> Hi,
>
> I'd like to announce a program I wrote to backup GnuPG and SSH keys as
> qrcodes on paper:
>
> paperbackup.py https://github.com/intra2net/paperbackup
>
> This is designed as fallback if all your regular backups failed to restore or
> were lost.
>
> Usage is like this:
>
> gpg2 --armor --export "User Name" >key.asc
> gpg2 --armor --export-secret-key "User Name" >>key.asc
> paperbackup.py key.asc
> paperrestore.sh key.asc.pdf | diff key.asc -
> lpr key.asc.pdf
>
> You'll find all the details, reasoning and examples in the README.
>
> Kind regards,
>
> Gerd
>
>
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Peter,

> So I think the three initial bytes of an MD5 would work well to detect
> typing errors.

I just implemented the line checksums as discussed.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 27/02/17 11:50, Gerd v. Egidy wrote:
> echo -n "line content to check" | md5sum | cut -c -6

Yes, that should work just as well in practice, I think. 24 bits of
checksum is slightly weaker than 32, but I don't think it matters.

> But I think a collision at the first 3 bytes is less likely with MD5 than one 
> with CRC. The MD5 sum changes drastically if just one bit flips.

I doubt CRC-32 would be worse than 32 bits of MD5, since CRC-32 is
designed to catch accidental errors[1]. I don't know how a CRC-32
truncated to 24 bits would behave. A truncated MD5 should be fine for
detecting accidental errors, though.

So I think the three initial bytes of an MD5 would work well to detect
typing errors.

Cheers,

Peter.

[1] Although it's probably better at physical noise in the transfer of
individual bits than typing mistakes in base64 data.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Peter,

thank you very much for helping with paperbackup.py and sending your python 
code.

> > Ideally it is a tool or combination of tools already deployed widely, like
> > sed and sort I used in paperrestore. This would make the checksums still
> > usable even when the source to paperbackup.py isn't available anymore.
> 
> It took me some fiddling... but using CRC RevEng[1] I got a checksum in
> Python that is compatible to POSIX cksum.
[...]
> $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) |
> sed 's/../\\x\0/g')|base64|cut -b-6

Yesterday, with your solution in mind, I had an idea how we could even further 
reduce dependencies and ease the use:

echo -n "line content to check" | md5sum | cut -c -6

MD5 may be broken as a secure hash, but it still makes a very good checksum. 
MD5 is well standardized and available and hashlib.md5() is included in 
python. 

Your solution uses base64 to show more bits of the checksum than my hex chars. 
But I think a collision at the first 3 bytes is less likely with MD5 than one 
with CRC. The MD5 sum changes drastically if just one bit flips.

What do you think?

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

By the way, don't worry about the license. I just slapped it on there
because you need /something/. (I didn't even look at paperbackup.py's
license, which was dumb, I would have put an MIT license on it otherwise.)

If you're going to use it, I assume you're just going to embed the few
lines of code there are into paperbackup.py. You have my permission to
use the code in posixcksum.py in paperbackup.py *without attribution*.
You don't have to name me, just use it.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 23/02/17 13:36, Gerd v. Egidy wrote:
> So I think that this would move the bar for a possible user of paperbackup.py 
> higher than I want to.

Yes, it should be easy to use. In fact, I've sometimes heard the 
complaint that "paperkey is not easy to install and/or use". That's 
really too bad that those people feel that way.

> Ideally it is a tool or combination of tools already deployed widely, like 
> sed 
> and sort I used in paperrestore. This would make the checksums still usable 
> even when the source to paperbackup.py isn't available anymore.

It took me some fiddling... but using CRC RevEng[1] I got a checksum in 
Python that is compatible to POSIX cksum.

The following Python:

>>> from posixcksum import PosixCkSum
>>> from base64 import b64encode
>>> crc, _ = PosixCkSum.sum_whole(bytearray(b'123456789'))
>>> b64encode(crc.to_bytes(4,byteorder='big'))[:4]
b'N3pg'

generates the same checksums as the following Bash code:

$ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | sed 
's/../\\x\0/g')|base64|cut -b-4
N3pg

This is done with the attached Python code. It is written for 
compactness rather than speed. Just re-implementing the crc function 
would probably be quicker.

HTH,

Peter.

[1] 
-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
#!/usr/bin/python3

# Copyright (c) 2017 Peter Lebbing 
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.

import binascii

class PosixCkSum(object):


"""Create a POSIX cksum-compliant checksum."""


def __init__(self):
"""Create new checksumming instance."""
self.n = 0
self.crc = 0x

def sum(self, bs):
"""Checksum another part of data.

IMPORTANT: the data in bs is DESTROYED.

"""
self.bit_reverse(bs)
self.crc = binascii.crc32(bs, self.crc)
self.n += len(bs)

def finish(self):
"""Finish checksum computation and return result.

After this, the object should no longer be used.

"""
if not self.n:
return self.crc, self.n
bs = bytearray(self.n.to_bytes((self.n.bit_length() + 7) // 8,
   byteorder='little'))
self.bit_reverse(bs)
self.crc = binascii.crc32(bs, self.crc)
crcb = bytearray(self.crc.to_bytes(4, byteorder='little'))
self.bit_reverse(crcb)
crc = int.from_bytes(crcb, byteorder='big')
return crc, self.n

@classmethod
def sum_whole(cls, bs):
"""Checksum a single piece of data.

IMPORTANT: the data in bs is DESTROYED.

"""
c = cls()
c.sum(bs)
return c.finish()

@staticmethod
def bit_reverse(bs):
"""Reverse the bits in every byte of the argument in-place"""
for i,b in enumerate(bs):
r = 0
t = 0x80
s = 0x01
while t:
if (b & t):
r |= s
t >>= 1;
s <<= 1;
bs[i] = r

if __name__ == '__main__':
# Checksum all files passed as arguments, or stdin if none
from sys import argv,stdin
if len(argv) == 1:
bs = bytearray(stdin.buffer.read())
crc, n = PosixCkSum.sum_whole(bs)
print(crc, n)
else:
for fn in argv[1:]:
if fn == '-':
bs = bytearray(stdin.buffer.read())
else:
with open(fn, 'rb') as f:
bs = bytearray(f.read())
crc, n = 

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 23/02/17 11:00, Gerd v. Egidy wrote:
> Seems you are trusted by much more people than me ;)

More people trust that that key is mine, they don't trust me as a
person, my actions or my certifications. dkg already answered that bit
:-). These are mostly people I've met at a keysigning party. They have
seen my passport and asserted that "Peter Lebbing" is as far as they can
tell indeed the person in possession of that key. They don't trust me
more than the next guy, because they don't know me personally.

> If we are talking centuries, I'd worry about the availability of gnupg as 
> much 
> as qrcodes.

If there is still software that can work with OpenPGP v4 keys, then you
can restore your private key from your paperkey-style backup. If there
is no more software that can work with OpenPGP v4 keys, what are you
going to do with your restored private key? Frame it and put it on the
wall? ;-)

> Not all decoders are capable of it, and if one qrcode is missing, the linking 
> is broken and you have to patch the decoder to still get some data.

Understood. Good to see you've thought it through.

> I used the largest error correction ratio possible.

Given the size of those QR codes on paper, you could use a camera that
is so elderly it has developed presbyopia and cataract and still scan
them succesfully! :-D

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

OpenPGP third-party certifications do not imply trust [was: Re: Announcing paperbackup.py to backup keys as QR codes on paper]

[Daniel Kahn Gillmor]

[ not on-topic for this thread, hence the subject change ]

On Thu 2017-02-23 05:00:54 -0500, Gerd v. Egidy wrote:
>> The certificate (aka public key) includes all signatures, all the data
>> on the keyserver. It's data you don't really need to back up since it is
>> public, and it can be huge. My key.asc file is 137,424 bytes following
>> your instructions.
>
> Seems you are trusted by much more people than me ;)

I'm calling this out because it's a common misconception, and i don't
want it to lie here unchallenged when someone is browsing the archives.

The people who "sign your key" (who have created an OpenPGP
certification that binds your primary key to your User ID) are only
identifying you and your key.  They have said nothing about "trust" by
making those certifications.

For example, I am happy to certify the identity and key of someone who i
do not trust at all, as long as i know who they are and they've asserted
their key to me in-person, or across some reliable, non-forgeable
transport.

So the fact that Alice has a dozen certifications on her key and Bob has
two doesn't mean that Alice is trusted by more people than Bob at all.
It just means that more people have been willing to publicly assert that
they know Alice's identity and key than have been willing to publicly
assert the same information about Bob.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Daniel Kahn Gillmor]

On Thu 2017-02-23 03:54:12 -0500, Thomas Jarosch wrote:
> In the interest of humanity and the cause of science, I've just tried again 
> with a throwaway key :) This time it worked just fine. The "only" thing 
> that's 
> changed is that I've upgraded from Fedora 22 to Fedora 25 since I last tried.

humanity and science thank you for your efforts :)

happy hacking,

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[NdK]

Il 23/02/2017 11:00, Gerd v. Egidy ha scritto:

> If we are talking centuries, I'd worry about the availability of gnupg as 
> much 
> as qrcodes. Both are publicly available standards, but I don't know if they 
> are still available and understandable by then. I'd recommend going to 
> plaintext on glass etched microfiche if you really want to cover that 
> timespan.
Well, when considering such a timespan there could be other (bigger)
issues... How long a today 'secure' key will remain secure? When will
quantum computers be widely available?
The only "guaranteed" crypto is information-theoretic one (neural
networks mutual learning, distant noisy sources, etc), where adversary's
probability of success is a function of the system parameters. But it's
quite impractical and AFAIK covers only interactive key agreement.

PS: in 100 years surely I won't (be here to) care if someone will be
able to read my mails or not :)

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

> You might consider using a font designed for OCR rather than the current
> font.

I tried to change to OCR-B or Inconsolata 
http://stackoverflow.com/questions/316068/what-is-the-ideal-font-for-ocr

but getting that to work with enscript is not easy, as you have to find and 
install afm and pfb into the correct directories. This goes a lot deeper than 
just installing packages provided by whatever disto you are using.

So I think that this would move the bar for a possible user of paperbackup.py 
higher than I want to.
 
> Additionally, base64 has look-alike characters, and the only checksum is
> for the whole key. So if it says "checksum failed" you've only learned
> that factoid. A checksum per line would be better, so you can say
> "checksum failed in line n".

Can you recommend a tool to create a short checksum (crc32?) for each line? 

Ideally it is a tool or combination of tools already deployed widely, like sed 
and sort I used in paperrestore. This would make the checksums still usable 
even when the source to paperbackup.py isn't available anymore.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

> I'm a little
> surprised that your code is as large as it is, too: using an alternate
> pipeline you might be able to significantly reduce code size.
> 
> (a) use Python 3's gpg module to export the secret key
> (b) paperkey --output-type raw --secret-key key.gpg --output key.raw

I want paperbackup.py to be independent and agnostic of gnupg. It should also 
be usable for e.g. ssh keys or ciphertext.

> (c) use Python 3's QR library to create a series of PNGs
> (d) use Wand or PythonMagick to convert the PNGs to PDF
> (e) save the PDF and you're done

I had some problems creating proper multipage pdfs, so I used PyX.

If you can come up with shorter sourcecode or less dependencies, I'm happy to 
take patches.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Peter,

> The certificate (aka public key) includes all signatures, all the data
> on the keyserver. It's data you don't really need to back up since it is
> public, and it can be huge. My key.asc file is 137,424 bytes following
> your instructions.

Seems you are trusted by much more people than me ;)

> $ gpg2 --armour --output key.asc --export-options export-minimal
> --export-secret-key [KEYID]

Thank you for your explanation and recommendation. I have adapted the readme 
on github.

> However, I'm running into a little problem here myself... GnuPG 2.1.18
> does not respect the "export-minimal" option for --export-secret-key,
> only for --export. So if you are using GnuPG 2.1, this will not work as
> intended.
> 
> This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now.

Thank you for checking and reporting this.

As it will not leave out important information, just add more data that is not 
strictly needed, it won't hurt the affected users much. Just a few more dead 
trees...

> Oh, as an aside, the advantage of paperkey is that it is
> self-describing. No matter what happens, as long as we can still use
> hexadecimal digits to describe binary content (which would be trivial to
> reimplement), we can reconstruct the binary private key file. Using QR
> codes has the disadvantage that if you cannot find a QR-code decoder for
> your platform in the future, reimplementing one is far from trivial. You
> are dependent on QR codes surviving as an actually supported data format.

What timespan are we talking about?

If we are talking decades, I have no doubts that some qrcode decoder will 
still be available, even if qrcodes aren't used anymore. There are several 
open source decoders available and included in linux distributions. Stuff like 
that tends to be available for a long time: you can still download packaged 
linux distros like Red Hat Linux 1.0 (released 1995) or Debian 0.91 (released 
1994) today, about 23 years afterwards.

If we are talking centuries, I'd worry about the availability of gnupg as much 
as qrcodes. Both are publicly available standards, but I don't know if they 
are still available and understandable by then. I'd recommend going to 
plaintext on glass etched microfiche if you really want to cover that 
timespan.

> Finally, I remember something about QR codes inherently supporting
> splitting data over multiple individual code blocks, specifically for
> data that is too large to fit in a single block. I don't know if it
> supports the number of blocks you need, but you might want to check it
> out.

I know of that feature and have deliberately decided against it:

Not all decoders are capable of it, and if one qrcode is missing, the linking 
is broken and you have to patch the decoder to still get some data.

I consider the plaintext linking and ordering I used more robust, see
https://github.com/intra2net/paperbackup#encoding-and-data-format

> Also, you say large QR codes are easily damaged by wrinkles and
> deformations. Is this perhaps related to the amount of error correction
> data included? You can tune the ratio of content data to error
> correction data, making a QR code more resilient to damage.

I used the largest error correction ratio possible.

> However, if
> you find that it is not unreadable individual pixels but rather the
> deformation of the total that is throwing off decoders, than I suppose
> the ratio doesn't help: it either can reduce it to the required square
> or it cannot, I'd think.

I haven't studied the decoding algorithms at that level of detail. If the 
deformation is irregular, I guess it affects some parts of a code more than 
others. Then a higher error correction ration will help.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[antony]

On February 21, 2017 9:34:17 AM EST, "Gerd v. Egidy" 
 wrote:
>Hi,
>
>I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
>qrcodes on paper:
>
>paperbackup.py 
>https://github.com/intra2net/paperbackup
>

Just wanted to say thanks for sharing your work. As for paperkey, I have an RSA 
4096 bit key. Without paperkey, the output for my key was around 23-24 pages. 
With paperkey (using base64 output), the output was around 19 pages, so the 
benefit was minimal. Also, the first time I tried, the decode process kept 
failing on one barcode from the output pdf, but I re-encoded it and tried again 
and the decode process verified correctly. The ability of zbar to process the 
images directly from the pdf was impressive IMO.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 22/02/17 16:10, Thomas Jarosch wrote:
> May be the internal packet format changed or needs adaption.

It is not an internal packet format by the way, it is defined in RFC
4880 (OpenPGP Message Format). And all GnuPG versions output their keys
formatted according to OpenPGP, so the problem you're experiencing is
more subtle.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 22/02/17 16:10, Thomas Jarosch wrote:
> When I think about long term storage, I'd rather rely on the full data
> instead of a snippet of the openpgp packets.

I understand that. However, let me point out that any errors parsing
will only occur while *creating* a backup with paperkey. Once it
succesfully parses the data, the result can be used without the program,
it is stand-alone and complete. No further "parsing errors" can occur.
Rejoining the private key can be done by hand.

Could you share a bit more details about the error you encountered? If
it is a problem with paperkey, I think we (as a community) would like to
know about it and hopefully fix it.

> The argument about re-downloading the public key from the keyservers is valid 
> though, but for the secret key a full backup is preferred in our use case.

All public data can be scattered all over the world and the internet,
and backed up and replicated in all manner of forms for resiliency.

In theory this goes for a private key with a good passphrase as well,
but that moves the point of failure to remembering the passphrase.
paperkey however can be used without a passphrase, and the result should
be guarded really well, unlike all the public data.

I'm not trying to convince you to do something differently than you do
now, I'm just trying to make the picture more complete. However, it
seems your solution to your use case depends on there being few
signatures on a key, as evidenced by my key needing 104 pages (that's
without the unnecessary duplication that resulted in the 208 pages I
mentioned earlier). I would not enjoy the amount of room this book
occupies in my safe, or scanning it.

> It's easy for the user to skip the public key backup.

Hm... once we have export-minimal for --export-secret-key :-).

> Also if the QR code scanning ever fails: There is base64 encoded text output
> at the end, too. That could be OCRed or typed in by hand if ever needed.
> (we use paperbackup.py just as additional backup)

You might consider using a font designed for OCR rather than the current
font.

Additionally, base64 has look-alike characters, and the only checksum is
for the whole key. So if it says "checksum failed" you've only learned
that factoid. A checksum per line would be better, so you can say
"checksum failed in line n".

> You can even use paperbackup.py to back up your ssh key :)

Yep. But if you trust GnuPG, and you have a paper backup of your OpenPGP
key, you could encrypt a copy of your SSH key with your OpenPGP key and
publish the encrypted file. Then as long as you have a paper backup of
your OpenPGP encryption subkey, you can just fetch and decrypt the SSH
key. This by the way goes for any piece of data, no matter how large,
including all the videos you shot of your children while they grew up
and would really dread to lose. Just encrypt them, back them up with
several backup providers online, and as long as your paper backup of
your OpenPGP key survives, so do the videos. It might even provide that
little extra motivation to be extra sure the backup of your OpenPGP key
can be depended on, now that you really do depend on it for something
you care deeply about! ;-D

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Thomas Jarosch]

Hi Peter,

On Wednesday, 22 February 2017 13:56:22 CET Peter Lebbing wrote:
> Oh, as an aside, the advantage of paperkey is that it is
> self-describing. 

I've tried paperkey with Gnupg 2.1.13 and it had trouble parsing the secret 
key data. May be the internal packet format changed or needs adaption.
When I think about long term storage, I'd rather rely on the full data
instead of a snippet of the openpgp packets.

The argument about re-downloading the public key from the keyservers is valid 
though, but for the secret key a full backup is preferred in our use case.
It's easy for the user to skip the public key backup.

Also if the QR code scanning ever fails: There is base64 encoded text output
at the end, too. That could be OCRed or typed in by hand if ever needed.
(we use paperbackup.py just as additional backup)

You can even use paperbackup.py to back up your ssh key :)

Cheers,
Thomas


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Robert J. Hansen]

> Oh, as an aside, the advantage of paperkey is that it is
> self-describing.

I'll chime in with another recommendation for Paperkey.  I'm a little
surprised that your code is as large as it is, too: using an alternate
pipeline you might be able to significantly reduce code size.

(a) use Python 3's gpg module to export the secret key
(b) paperkey --output-type raw --secret-key key.gpg --output key.raw
(c) use Python 3's QR library to create a series of PNGs
(d) use Wand or PythonMagick to convert the PNGs to PDF
(e) save the PDF and you're done


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

Hello Gerd!

Thank you for sharing your program with the world! I'm sure it will be
useful.

On 22/02/17 09:38, Gerd v. Egidy wrote:
> You are right that this is probably more than strictly neccessary. But if you 
> look at my example output on github, a regular public and private key in 
> qrcodes and plain is just 9 pages. 

I beg to differ. Following your instructions, my PDF is 208 pages long!

The certificate (aka public key) includes all signatures, all the data
on the keyserver. It's data you don't really need to back up since it is
public, and it can be huge. My key.asc file is 137,424 bytes following
your instructions.

Additionally, --export-secret-key actually includes everything from
--export, it just *adds* the secret key material to it. So there is no
need to do both --export and --export-secret-key; it just doubles the
information from --export.

What you're probably looking for is:

$ gpg2 --armour --output key.asc --export-options export-minimal
--export-secret-key [KEYID]
$ paperbackup.py key.asc
$ paperrestore.sh key.asc.pdf | diff key.asc -
$ lpr key.asc.pdf

However, I'm running into a little problem here myself... GnuPG 2.1.18
does not respect the "export-minimal" option for --export-secret-key,
only for --export. So if you are using GnuPG 2.1, this will not work as
intended.

This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now.

Leaving aside this bug, export-minimal will achieve your goal: it will
only include the currently valid parts of the key without any
certifications by other keys. It is all you need to have a working key.
The certifications by other keys are on the keyservers.

Oh, as an aside, the advantage of paperkey is that it is
self-describing. No matter what happens, as long as we can still use
hexadecimal digits to describe binary content (which would be trivial to
reimplement), we can reconstruct the binary private key file. Using QR
codes has the disadvantage that if you cannot find a QR-code decoder for
your platform in the future, reimplementing one is far from trivial. You
are dependent on QR codes surviving as an actually supported data format.

Finally, I remember something about QR codes inherently supporting
splitting data over multiple individual code blocks, specifically for
data that is too large to fit in a single block. I don't know if it
supports the number of blocks you need, but you might want to check it
out. Also, you say large QR codes are easily damaged by wrinkles and
deformations. Is this perhaps related to the amount of error correction
data included? You can tune the ratio of content data to error
correction data, making a QR code more resilient to damage. However, if
you find that it is not unreadable individual pixels but rather the
deformation of the total that is throwing off decoders, than I suppose
the ratio doesn't help: it either can reduce it to the required square
or it cannot, I'd think.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Daniel,

> > gpg2 --armor --export "User Name" >key.asc
> > gpg2 --armor --export-secret-key "User Name" >>key.asc
> > paperbackup.py key.asc
> 
> this is a cool idea.  however, it seems like you might be backing up
> more than most people would need.  For most folks, their OpenPGP
> certificates (public keys) are stored on the public keyservers.  Or at
> least their friends have a copy of them :)
> 
> Even if you want the whole certificate, you've duplicated most of the
> material here -- just the data produced by --export-secret-key should be
> sufficient to reconstruct everything.  Probably, putting less data in
> your qrcode backup will make the backup more robust during recovery..

You are right that this is probably more than strictly neccessary. But if you 
look at my example output on github, a regular public and private key in 
qrcodes and plain is just 9 pages. 

If some of the qrcodes containing the public key could not be decoded during 
recovery, it won't affect the codes of the private key. The user will just 
have to remove the ascii armored remnants of the public key. So adding the 
public key won't hurt.

paperbackup.py doesn't know or understand public or private keys, it just 
cares about text files. So the user is always free to decide what parts to 
back up.

> Are you aware of David Shaw's paperkey?
> 
>   http://www.jabberwocky.com/software/paperkey/

Yes, I have linked it in the README on github, section "Similar projects".
 
> This produces significantly less data (still in text form, though), so
> it could be combined with your approach to have a nice big, robust,
> scannable recovery mechanism.

Correct. But unless you want to backup hundreds of keys I don't think it is 
necessary to think much about data reduction. It is just a few pages of paper 
and printing and scanning them is just a matter of a few minutes. 

This is the beauty of qrcodes in contrast to OCR and manually typing.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Daniel Kahn Gillmor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Gerd--

On Tue 2017-02-21 09:34:17 -0500, Gerd v. Egidy wrote:
> I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
> qrcodes on paper:
>
> paperbackup.py 
> https://github.com/intra2net/paperbackup
>
> This is designed as fallback if all your regular backups failed to restore or 
> were lost.
>
> Usage is like this:
>
> gpg2 --armor --export "User Name" >key.asc
> gpg2 --armor --export-secret-key "User Name" >>key.asc
> paperbackup.py key.asc
> paperrestore.sh key.asc.pdf | diff key.asc -
> lpr key.asc.pdf

this is a cool idea.  however, it seems like you might be backing up
more than most people would need.  For most folks, their OpenPGP
certificates (public keys) are stored on the public keyservers.  Or at
least their friends have a copy of them :)

Even if you want the whole certificate, you've duplicated most of the
material here -- just the data produced by --export-secret-key should be
sufficient to reconstruct everything.  Probably, putting less data in
your qrcode backup will make the backup more robust during recovery..

So for most folks, the critical backup that they need is likely to be
only the secret key material itself, since the public key material and
signatures and the like can all be retrieved from from the keyserver
network or from friends.

Are you aware of David Shaw's paperkey?

  http://www.jabberwocky.com/software/paperkey/

This produces significantly less data (still in text form, though), so
it could be combined with your approach to have a nice big, robust,
scannable recovery mechanism.

thanks for publishing your work!

  --dkg
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlitEsgACgkQFJitxsGS
MjfnZQ//ediyODKSSDEj3wEEobXd+27VTv3oOS6EpBUDxyse3ttMAb1q9EBgzJC/
DJAYC1vOqyYzQ7+7uLVAKShE2rMWDhTnxAbIYsbqRpxeS0vGsn5L3yWpiT+u5LkN
sBXONHO5MxDH1kQDZ9+muFZWYUBTSKbJLLHN0R5uk1PqvVRXBMT3HDFusqeS0EBI
W+lBKGGABBGk1P8/Sc1tOX9WbkA5aQxNhGq5Rq0E4FUrR7J6IlAKGDqjVmCHs1++
BzMVKqkfZm2++PQXpGyzCadkTL9oTK4+zMz3E6cvQtwlNWZBZLW1vPZPNwRWBekK
VNbZEyIOuSSZTR/jmDyh7dNDAzsjjKF+1Gspu9uDFWVHUbz72hdUzmyRB0RG8DfN
XfE8zscyJlmJfTccgRYzfuTNXU9QtnlwyThvYyrvZOQ/WMSxfYe+ST3neJOGGB7j
UFnhj4DgfSNVbXT6mEOLWEos3S21YSN8hMiLkOqvyF7+Tnuq98hyEESAX0BRLAjw
Jo1eLkkgdAaB5Ww08VoxrmArSS7dCpvyn1OpeuOvC0BZuKBKJI+93ZuWSAKDRdNr
ouI355qDnOun7ut9cAl1fC0r6ws9qjeGNXTgQUHGAu43bs0A2rkhzaPg0DdHYvrQ
ME3mdC45HOT+EYCysJj9DNueD9ZO/W235MPWTHOcD17uBi5iHr4=
=DPyt
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi,

I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
qrcodes on paper:

paperbackup.py 
https://github.com/intra2net/paperbackup

This is designed as fallback if all your regular backups failed to restore or 
were lost.

Usage is like this:

gpg2 --armor --export "User Name" >key.asc
gpg2 --armor --export-secret-key "User Name" >>key.asc
paperbackup.py key.asc
paperrestore.sh key.asc.pdf | diff key.asc -
lpr key.asc.pdf

You'll find all the details, reasoning and examples in the README.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users