Paperkey 1.3

[David Shaw]

On Jan 7, 2013, at 11:05 AM, David Smith <Dave.Smith at st.com> wrote:

> On 01/04/13 17:31, David Shaw wrote:
>> Sure, paperkey supports piping the output into whatever code generator you like:
>> 
>> gpg --export-secret-key mykey | paperkey --output-format raw | your-bar-code-generator
>> 
>> However, 2D bar codes have some of the problems that paperkey is intended to address.  You need a 'thing' (a process, a device, etc) to read them, and part of the point of paperkey is that it's supposed to be the backup of last resort, and thus readable by a human without any special hardware involved.
> 
> True, but OTOH, whilst hardware devices do tend to become obsolete
> relatively quickly, the algorithms tend to have more longevity.  For
> example, you might struggle to find one of the earlier 1d bar code
> reader pens that I remember from the 1980s around now, and even the
> software used for reading and interpreting them will probably have
> disappeared, but the overall mechanism is still widely used.
> 
> I would suggest that we are going to have "devices for scanning paper to
> a digital image" for quite a few years yet (whether they are SCSI-based
> ones from years ago, through USB-connected multi-function printers, to
> digital cameras and beyond.  2d bar codes (and the algorithms needed to
> process them) are well-specified, so even if the existing software
> becomes unusable, it could be re-written for a new platform.

This is exactly the point.  Algorithms may stay around, but if have to reconstruct printed data given only knowledge of the encoding algorithm (without the hardware intended to read it, or the software intended to reconstruct the data), well, it's possible, but sure as heck won't be quick or cheap for someone with image processing experience, or even possible for the majority of people without that knowledge.

Paperkey often spawns this discussion about how we could use scannable paper images using x, y, or z encoding, or favorite brands of burnable CDs that will last, etc. No doubt, favorite flash brands will be discussed in the future.  These are all interesting discussions, but it's sort of missing the point.  Paperkey is a way to store your key in a way that needs nothing more than eyes and a keyboard to restore, and uses a medium that can last for many times the greatest human lifespan.  The disadvantage is that it's potentially annoying to recover a key from paper (i.e. typing in a several hundred hex bytes without error).  There are per line checksums to make this easier, so you know where a mistake is, and you can use OCR to save on typing, but still, you have to get the bytes from paper into a computer somehow.  All that is fine, as paperkey does not, and is not intended to, replace a backup of your secret keys. It's not where you should be going if your primary storage goes poof.

> I'm not saying that there isn't a place for printing the key out in
> ASCII; just that it might be a good idea to print it out as a 2d barcode
> as well

Exactly.  Keep proper backups!  Paperkey is for when that backup fails, for when your CD stops working, for when the driver for your scanning pen isn't maintained on your new computer, or for when cosmic rays have rendered your flash corrupt.  It's the backup of last resort, and as such should need nothing other than nothing other than the ability to read numbers and type them in again to restore, hence my comment about not favoring a 2D barcode paperkey.

David