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 <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
