Printing Keys and using OCR.

[Joseph Oreste Bruni]

Fingerprint:
C54A C9DD 84AD C6FC D343  67C4 5195 D63A CD55 18C7

 
On Wednesday, May 16, 2007, at 12:44PM, "David Shaw" <dshaw at jabberwocky.com> wrote:
>On Tue, May 15, 2007 at 09:07:35AM -0500, Ryan Malayter wrote:
>
>> I would suggest using plain old base64 ASCII and a large version of a
>> font like OCR-A or OCR-B. You can include par2 information, also
>> base64 encoded, but finding software to use that data for recovery may
>> be difficult many years in the future. Simply printing multiple copies
>> of the page for OCR and diffing for errors would probably be easier.
>
>Yes.
>
>I've actually done quite a bit of work on "paper escrow" systems like
>this.  It tends to raise a few eyebrows, but in reality paper and ink
>in a dark place has wonderful archival characteristics - better than
>the usual CD-R, memory stick or (luckily not much used anymore)
>floppy.
>
>One trick that can be done when paper escrowing OpenPGP keys is to
>only print the part you care about.  OpenPGP secret keys are heavily
>padded with non-secret data.  In fact, the secret key contains a
>complete copy of the public key.  Since the public key generally
>doesn't need to be escrowed (most people have many copies of it on
>various keyservers, web pages, etc, etc), it would not be hard to
>write a program that extracts just the secret bytes and prints that.
>To reconstruct, you'd re-enter those bytes (whether by hand or via
>OCR) and use them to transform your public key into a secret key.
>
>For example, the regular DSA+Elgamal secret key I just tested comes
>out to 1281 bytes.  The secret parts of that (plus some minor packet
>structure) come to only 149 bytes.  It's a lot easier to enter 149
>bytes correctly.
>
>David
>

Does this sort of functionality exist in gpg today? This sounds like a great solution.
My public key contains a small JPEG that adds about 1200 bytes. But if that
is replicated in my secret key, I'd not care to hand enter it in the case of a 
paper-based recovery.