Re: paperkey // recommended OCR font ?
> "v" == vedaal writes: v> If so, what is the recommended font and size to be used for accurate OCR ? v> OCR-A, OCR-B, Ordinary Courier 10, other ? I've tried it once. I used ocr-a since it was available and seemed likely to be easiest to scan. And, although some might disagree, I also find it easy to read. I just gave it a try w/o paper, using mpage to generate postscript, OCRA for the font, gs to render the ps to pbm, and gocr to extract the text. I needed to run >>tr \;_ ::<< on the extracted text, but with that paperkey was able to generate a new secring. So be aware that you may need to massage the ocr'ed data to recover paperkey's format, but it should mostly work. Using OCRB or Courier, gocr wasn't able to recover the text well enough. Tesseract did better with Courier-Bold, but needed >>tr Ol 01<<. But tesseract *badly* fails to grok OCRA! I suspect that actual printing and scanning won't be *too* much worse. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
key revocation reasons in frontends/gnupg
Hi, I was thinking/discussing rfc2440 5.2.3.22. Reason for Revocation. I'd love to hear opinions why it would or wouldn't make sense to have this information easy(easier) available with gnupg or some frontends. I personally find it very convenient to point people to that packet to say that I for example have a new key that superseded the old one. But maybe you have other opinions? For sake of easiness I'll paste here the relevant RFC section: (1 octet of revocation code, N octets of reason string) This subpacket is used only in key revocation and certification revocation signatures. It describes the reason why the key or certificate was revoked. The first octet contains a machine-readable code that denotes the reason for the revocation: 0x00 - No reason specified (key revocations or cert revocations) 0x01 - Key is superceded (key revocations) 0x02 - Key material has been compromised (key revocations) 0x03 - Key is no longer used (key revocations) 0x20 - User id information is no longer valid (cert revocations) Following the revocation code is a string of octets which gives information about the reason for revocation in human-readable form (UTF-8). The string may be null, that is, of zero length. The length of the subpacket is the length of the reason string plus one. Ciao, Kwadronaut ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg not working with RHEL 4
On 01/04/2013 04:09 PM, Anilkumar Padmaraju wrote: > This is first time I am upgrading gnupg. Are there any steps or document > to download source, compile, and upgrade? I did some search in google, but > could not find detailed one. > > After upgrading do I have to do gpg --gen-key or it is only needed when we > install for the first time? GnuPG is software for working with OpenPGP material (keys, signatures, and encrypted messages). Newer versions of GnuPG will continue to work with pre-existing OpenPGP material. This means that you should not need to generate another OpenPGP key just because your version of GnuPG was upgraded. Your existing OpenPGP key should continue to work. hth, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Paperkey 1.3
On 04-01-2013 20:30, David Shaw wrote: > That's a very good point. Do you know of any studies on the projected life > of flash > when used as backup? That depends strongly on the type of flash. NOR-flash, which is not used any more in new devices gave problems after not many rewrites. NAND flash is much more durable. However, when you buy a new device and use it for long term backup purposes (no/very few rewrites) AFAIK it can last very long. The main thing that could damage it when it's just stored is radioactive radiation like cosmic rays. Personally I'm a heavy user of USB flash, also for backups, and the only problems I ever had were software related (e.g. a 64-bit windows 7 computer that had the tendency to corrupt Truecrypt images). Of cource this is anecdotical and I seem to be lucky about it; my oldest CD-ROM backups from 1998 are also still readable. > The few numbers I've seen at manufacturers websites about retention > specifically, > suggest it's around 10 years (depending on how well the flash is stored - heat > makes it die quicker, etc). My oldest flash drive is still readable but it's not 10 years old yet. But I am keeping it and will test it every now and then. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
