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. 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, so that if recovery were necessary and the appropriate HW and SW were available, that could be used to recover substantially more data (since the whole key record could be encoded in a relatively small space), and then fall back on the ASCII version if the barcode is unrecoverable. _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
