backing up keys

[Thomas Harning Jr.]

On Tue, Nov 17, 2015 at 9:58 AM Andrew Gallagher <andrewg at andrewg.com>
wrote:

> On 17/11/15 12:39, James wrote:
> > All,
> >
> > I'm new to GPG and am hoping to learn the ropes. Please forgive any
> > ignorant questions.
> >
> > (a) are there any recommended methods by which to back up your private
> > and public keys? I've seen some "paper" methods (paperkey) and some
> > GitHub gists that have taken the private key, broken it in several
> > pieces and used QR codes to back up. Which is better? Does it matter?
>
> "Better" really depends on your use case. Are you likely to forget your
> passphrase? Are you going to keep your USB backup drive in a floor safe?
> Are you expecting your home to be searched by the feds (or the mob)? I
> don't think there is One Correct Answer to that one...
>
> > (b) is your public key embedded in your private key? If you're not
> > actually uploading your private key to a keyserver (perhaps using the
> > key to secure data / files instead of email, thus no need for
> > keyserver), is it sufficient to back up the private key only, or
> > _must_ I back up both files?
>
> No, there is no public key data embedded in the private key, but you can
> regenerate the important mathematical bits of the public key from the
> private key, and you can fill in your name, email etc. from memory. So
> it's not absolutely necessary - but it is convenient.
>
> Of course, the backup of your public key does not need to be secure.
>
> > (c) Isn't the private key itself encrypted via AES256 when secured
> > with a passphrase? If so, assuming the passphrase is secure enough,
> > isn't it sufficient to upload this file to Dropbox, etc. for safe
> > keeping? Would appreciate both real-world and theoretical commentary
> > on this point.
>
> Brute forcing a password is always easier than brute forcing the key
> itself (otherwise you'd be typing in your entire private key by hand!),
> so if (when) dropbox do leak the key data you've given the Bad People a
> shortcut.
>
> > (d) as best I can tell, the --armor flag is used to dump the key to
> > ASCII. The gpg documentation[1] seems to indicate that paperkey works
> > better at backing up to paper. Is there some reason why? Can't we
> > simply run --armor, print the output and then use OCR to pull the key
> > back in in case of emergency?
>
> That's fine if your OCR is perfect and your paper never gets folded or
> stained or torn, but ascii-armored data has no checksum or error
> correction so you may suddenly discover your paper backup is unusable.
> And such discoveries usually happen at the worst moment. ;-)
>
> Andrew.
>
I wrote up a blog post a while back illustrating some backup mechanisms:
http://blog.eharning.us/2011/04/key-backup-for-paranoid.html

The PaperBack (http://ollydbg.de/Paperbak/) tool creates backups for data
that can span multiple sheets of paper and have a varying level of
redundancy and resolution.
Checking out a backup made quite a while ago, since the dots were quite
large, there wasn't much degradation in decoding ...barely activating
redundancy measures. It should do well even if you fold the paper as even
if you fold it in quarters, many of the squares should remain unmarred....
I archived my paper backup inside a sealed document mailer - a nice help
against folding and useful marker if it were opened without my knowledge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151117/303b6c4a/attachment.html>