Re: Paperkey 1.3

2013-01-13 Thread David Shaw
On Jan 7, 2013, at 11:05 AM, David Smith dave.sm...@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


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-08 Thread John Clizbe
I.V. Frost wrote:
 
 Am I the only having trouble both the key for this message and the one
 with the binaries? My installation tells me it is not Key ID:
 0x99242560 but key 0xA1BC4FA4 which is not found on any server that I use.
 

Something sounds odd about the search criteria or keyserver selection.

Searching for the subkey 0xA1BC4FA4:
http://keyserver.gingerbear.net:11371/pks/lookup?search=0xA1BC4FA4fingerprint=onop=index

returns the key:

Search results for '0xa1bc4fa4'

Type bits/keyID Date   User ID
pub  4096R/99242560 2002-01-28 David M. Shaw ds...@jabberwocky.com
 Fingerprint=7D92 FD31 3AB6 F373 4CC5  9CA1 DB69 8D71 9924 2560


This should be true of any of the SKS keyservers out there.
(I'm syncing with 75 other servers)

-- 
John P. Clizbe  Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
 mailto:pgp-public-k...@gingerbear.net?subject=HELP

Q:Just how do the residents of Haiku, Hawai'i hold conversations?
A:An odd melody / island voices on the winds / surplus of vowels




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

2013-01-08 Thread Mark H. Wood
On Mon, Jan 07, 2013 at 05:54:15PM +0100, Peter Lebbing wrote:
 On 07/01/13 16:39, Mark H. Wood wrote:
  I'd suggest assuming some periodic read-only use, since we *should* be
  testing our backups regularly to discover decay *before* it makes
  something irretrievable.
 
 I would assume the decay to make it irretrievable the moment you discover
 it. Hoping the bit flips in a non-vital piece of (meta)data seems like a
 risky backup strategy.

[Hmmm, we are diverging a bit from Paperkey.]

This is why backup formats typically have internal redundancy.
(Printing the data as characters on paper adds a *lot* of redundancy.)
Depending on the medium, you might include error-correcting codes that
can recover from single-bit errors.  If you catch it at that stage,
you can copy it out and discard the failing medium.

Some codes will also detect errors that can't be corrected, so that
you know *now* to throw this medium away and make a new copy of your
other backup.  (You *do* have another backup?)  If you wait, they may
both turn out to be corrupt.

Every backup medium decays.  Long-term backups should be:

o  armored against bit-level decay;
o  tested regularly to detect degradation in progress;
o  replicated (and the replicas housed separately);
o  periodically refreshed or copied to new media.

I realize that most of us don't do any of that which didn't come with
the software, but we should. :-/

Of course, if an active device (like a flash stick) just stops working
and starts smoking, nothing can be recovered from it.  That's one of
the reasons you keep two of them.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
There's an app for that:  your browser


pgp6zjqM1VidT.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Paperkey 1.3 // very durable but often overlooked backup medium

2013-01-08 Thread vedaal
Back in the shrouded mists of time, in the last millenium, before digital media 
were widely accessible, 
many libraries and archives used to back up data on microfiche.
Many of them had built in printers, so that 'text' data could be retrieved, 
printed out, 
(and then, as the technology became widely available), scanned into digital 
format.

http://www.wisegeek.org/what-is-microfiche.htm

The above article gives the following interesting (?overly optimistic?) 
durability estimate:

=[ begin quote ]=

The polyester material on which the images are printed is also very stable and, 
if kept in a temperature controlled environment, is estimated to last as long 
as 500 years.
 CD-ROMs are estimated to last for about 75 - 100 years, 
depending on the materials they are made of and how they are stored.

=[ end quote ]=

(as an old darkroom BW hobbyist, I remember specific instructions on how to 
prepare prints for 'Archival Quality' 
[adjust development time so that the print could tolerate 2 minutes in a fixer 
tray without overly darkening],
this produced an estimate then of 75 year durability.)

Preserving only monochrome text probably has much greater durability.

Anyone come across specific recommendations for paper, printer, and storage 
recommendations for 'Archival Paper Backup'  ?


TIA

vedaal


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3 // very durable but often overlooked backup medium

2013-01-08 Thread Avi
These sites may prove interesting:


http://www.familyarchives.com/pages/documents-how-to-preserve-your-documents.html

http://www.archives.gov/preservation/holdings-maintenance/index.html
http://www.ala.org/alcts/resources/preserv/presvphotocop

This book, perhaps:
http://www.amazon.com/gp/product/0743264169/#reader_0743264169

--Avi


User:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) avi.w...@gmail.com

   Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E
29F9


On Tue, Jan 8, 2013 at 12:49 PM, ved...@nym.hush.com wrote:

 Archival Paper Backup
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-07 Thread Mark H. Wood
On Fri, Jan 04, 2013 at 02:30:43PM -0500, David Shaw wrote:
 On Jan 4, 2013, at 9:27 AM, Johan Wevers joh...@vulcan.xs4all.nl wrote:
 
  On 04-01-2013 5:42, David Shaw wrote:
  
  Paperkey 1.3 is released.
  
  You might want to update the website, it reads a bit outdated.
  CD/DVD-ROMs are going the way of the floppy disc; flash memory is much
  more reliable than either. Future support of USB ports or memory card
  readers seems the biggest concern for me.
 
 That's a very good point.  Do you know of any studies on the projected life 
 of flash when used as backup?  I've read anecdotal numbers as low as 5 years, 
 and marketing claims are always huge (100 years!), but most of what I see is 
 about the lifespan is when the flash is actively used (so running out of 
 read/write cycles), rather than the on-the-shelf lifespan of already written 
 data.

I'd suggest assuming some periodic read-only use, since we *should* be
testing our backups regularly to discover decay *before* it makes
something irretrievable.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
There's an app for that:  your browser


pgpYsgIGEe4e6.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-07 Thread Peter Lebbing
On 07/01/13 16:39, Mark H. Wood wrote:
 I'd suggest assuming some periodic read-only use, since we *should* be
 testing our backups regularly to discover decay *before* it makes
 something irretrievable.

I would assume the decay to make it irretrievable the moment you discover
it. Hoping the bit flips in a non-vital piece of (meta)data seems like a
risky backup strategy.

Flash memory stores its data as an electrical charge, which can leak away.
It does so very slowly, but it still does[1]. We are talking about years.
And reading a cell does not refresh it, so read-only use will in principle
not do anything to extend the storage time.

Peter.

[1] Johan Wevers mentioned radioactive radiation. Sounds plausible to me,
that should be capable of knocking electrons away, I'd think as a layman.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-07 Thread David Smith
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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-07 Thread Josef Schneider
On Mon, Jan 7, 2013 at 5:54 PM, Peter Lebbing pe...@digitalbrains.com wrote:
 Flash memory stores its data as an electrical charge, which can leak away.
 It does so very slowly, but it still does[1]. We are talking about years.
 And reading a cell does not refresh it, so read-only use will in principle
 not do anything to extend the storage time.

Still you can't be sure that the controller or flash cells won't just
stop working.
Yesterday, a new MicroSD card of mine just stopped working.
At first one folder was unreadable and fsck didn't work, then after
unplugging and re-plugging it all file names where gibberish, the card
got hot and I unplugged it.
Since then it's detected as unformated and no write access is possible.
This is the second MicroSD card where this happens for me. While
yesterday this was after less than a day, the other one broke after
about a month of heavy usage in my smart phone.
And while with a CD or DVD you probably still can read parts of the
data (especially if you have e.g. PAR2 files to recover it) if a flash
storage of any kind stops working, realistically you can't do anything
to rescue even parts of the data.
And while most hard disks that broke showed some signs of that (via
SMART or increased sound level) all flash memory devices more or less
stopped working from one moment to the other. (but then, I don't have
very much data)
So I wouldn't trust any flash memory for long time storage.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-05 Thread Johan Wevers
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


Re: Paperkey 1.3

2013-01-04 Thread Branko Majic
On Thu, 3 Jan 2013 23:42:07 -0500
David Shaw ds...@jabberwocky.com wrote:

 Paperkey 1.3 is released.  This adds ECC key support (both ECDH and
 ECDSA) as well as a few more minor tweaks.
 
 Source and Win32 binaries are available at:
   http://www.jabberwocky.com/software/paperkey/

Curious piece of software. Certainly not something that comes to mind
right away for making backups.

I wonder if you could back-up even more by using 2D bar code for an
output?

Best regards

-- 
Branko Majic
Jabber: bra...@majic.rs
Please use only Free formats when sending attachments to me.

Бранко Мајић
Џабер: bra...@majic.rs
Молим вас да додатке шаљете искључиво у слободним форматима.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread Johan Wevers
On 04-01-2013 5:42, David Shaw wrote:

 Paperkey 1.3 is released.

You might want to update the website, it reads a bit outdated.
CD/DVD-ROMs are going the way of the floppy disc; flash memory is much
more reliable than either. Future support of USB ports or memory card
readers seems the biggest concern for me.

-- 
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


Re: Paperkey 1.3

2013-01-04 Thread Werner Koch
On Fri,  4 Jan 2013 15:27, joh...@vulcan.xs4all.nl said:

 CD/DVD-ROMs are going the way of the floppy disc; flash memory is much
 more reliable than either. Future support of USB ports or memory card

FWIW: Some time ago I copied a bunch of ~25 years old 5.25 floppies to a
disk.  I had only problems with some of the very cheap or the dusted,
wet and oiled ones stored for too many years in my non-heated garage.

Nobody has experience with flash for more than a decade.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread Thomas Harning Jr.
You may want to check out my blog post about key backup[1]. In it I
mention two bar-code style backup solutions:
 * PaperBack [2]
 * Twibright Optar [3]

I also investigated QR codes and other 2D bar codes.. however they did
not seem to scale well to large amounts of data...

I found that PaperBack, while being a Win32 app (runs fine in Wine)
works beautifully for storing quite a bit of data with redundancy and
handling for user-level printers. Quoting the page If you have a good
laser printer with the 600 dpi resolution, you can save up to 500,000
bytes of uncompressed data on the single A4/Letter sheet. ... quite a
bit to store your entire secret keyring ... though you could use
paperkey + this to permit bumping up redundancy / dot-size quite a
bit.

Twibright Optar has quite a bit of promise, but requires quite a bit
of pre-processing and noise removal (not to mention source-code edit
to change dot-size to work nicely with non-super printers).



1: http://blog.eharning.us/2011/04/key-backup-for-paranoid.html
2: http://ollydbg.de/Paperbak/
3: http://ronja.twibright.com/optar/

On Fri, Jan 4, 2013 at 4:01 AM, Branko Majic bra...@majic.rs wrote:
 On Thu, 3 Jan 2013 23:42:07 -0500
 David Shaw ds...@jabberwocky.com wrote:

 Paperkey 1.3 is released.  This adds ECC key support (both ECDH and
 ECDSA) as well as a few more minor tweaks.

 Source and Win32 binaries are available at:
   http://www.jabberwocky.com/software/paperkey/

 Curious piece of software. Certainly not something that comes to mind
 right away for making backups.

 I wonder if you could back-up even more by using 2D bar code for an
 output?

 Best regards

 --
 Branko Majic
 Jabber: bra...@majic.rs
 Please use only Free formats when sending attachments to me.

 Бранко Мајић
 Џабер: bra...@majic.rs
 Молим вас да додатке шаљете искључиво у слободним форматима.

 ___
 Gnupg-users mailing list
 Gnupg-users@gnupg.org
 http://lists.gnupg.org/mailman/listinfo/gnupg-users




-- 
Thomas Harning Jr. (http://about.me/harningt)

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread David Shaw
On Jan 4, 2013, at 4:01 AM, Branko Majic bra...@majic.rs wrote:

 On Thu, 3 Jan 2013 23:42:07 -0500
 David Shaw ds...@jabberwocky.com wrote:
 
 Paperkey 1.3 is released.  This adds ECC key support (both ECDH and
 ECDSA) as well as a few more minor tweaks.
 
 Source and Win32 binaries are available at:
  http://www.jabberwocky.com/software/paperkey/
 
 Curious piece of software. Certainly not something that comes to mind
 right away for making backups.
 
 I wonder if you could back-up even more by using 2D bar code for an
 output?

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.

You could also back up your whole key via a 2D bar code (without using paperkey 
at all) but then you're backing up a lot of redundant data, giving you a larger 
image.  Of course, this may not be a big deal if the intent is to scan it back 
in again rather than type it back in again.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread Klaus Neumann
On 01/04/2013 06:27 AM, Johan Wevers wrote:
 On 04-01-2013 5:42, David Shaw wrote:
 
 Paperkey 1.3 is released.
 
 You might want to update the website, it reads a bit outdated.
 CD/DVD-ROMs are going the way of the floppy disc; flash memory is much
 more reliable than either. Future support of USB ports or memory card
 readers seems the biggest concern for me.
 
Support for USB ports or card readers will not disappear over night.
Whenever the next better medium becomes common, you simply transfer your
back-ups. No reason to be concerned, IMHO.

-- 
Best regards,
Klaus
--
PGP/GPG public keys at http://pgp.mit.edu
_
“Political language… is designed to make lies sound truthful and murder
respectable.”
George Orwell

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread David Shaw
On Jan 4, 2013, at 9:27 AM, Johan Wevers joh...@vulcan.xs4all.nl wrote:

 On 04-01-2013 5:42, David Shaw wrote:
 
 Paperkey 1.3 is released.
 
 You might want to update the website, it reads a bit outdated.
 CD/DVD-ROMs are going the way of the floppy disc; flash memory is much
 more reliable than either. Future support of USB ports or memory card
 readers seems the biggest concern for me.

That's a very good point.  Do you know of any studies on the projected life of 
flash when used as backup?  I've read anecdotal numbers as low as 5 years, and 
marketing claims are always huge (100 years!), but most of what I see is about 
the lifespan is when the flash is actively used (so running out of read/write 
cycles), rather than the on-the-shelf lifespan of already written data.

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).

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread I.V. Frost

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Am I the only having trouble both the key for this message and the one
with the binaries? My installation tells me it is not Key ID:
0x99242560 but key 0xA1BC4FA4 which is not found on any server that I use.

David Shaw made the following observation on 1/3/2013 10:42 PM:

 Hi folks,

 Paperkey 1.3 is released. This adds ECC key support (both ECDH and
 ECDSA) as well as a few more minor tweaks.

 Source and Win32 binaries are available at:
 http://www.jabberwocky.com/software/paperkey/

-BEGIN PGP SIGNATURE-
Comment: what is essential is invisible to the eye
Comment: - Antoine de Saint Exupery
 
iEYEAREIAAYFAlDm96wACgkQsMrrDTRrXem+cQCgpf9rv9Zj7KHr9CMezbN0YjV6
f/gAn174BhbDynOMYspBeKFztlK//xd/
=ZjMc
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Paperkey 1.3

2013-01-04 Thread David Shaw
On Jan 4, 2013, at 12:16 PM, I.V. Frost ivfrost2-m...@yahoo.com wrote:

 
 -BEGIN PGP SIGNED MESSAGE- 
 Hash: SHA256 
  
 Am I the only having trouble both the key for this message and the one with 
 the binaries? My installation tells me it is not Key ID: 0x99242560 but key 
 0xA1BC4FA4 which is not found on any server that I use.

0xA1BC4FA4 is a subkey on 0x99242560.  It should be available on the keyserver 
network.

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Paperkey 1.3

2013-01-03 Thread David Shaw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Paperkey 1.3 is released.  This adds ECC key support (both ECDH and
ECDSA) as well as a few more minor tweaks.

Source and Win32 binaries are available at:
  http://www.jabberwocky.com/software/paperkey/

Enjoy!

David
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQEcBAEBAgAGBQJQ5l03AAoJEP6ninqhvE+ka0MH/Ah32BaP018tuX6WIFtauc7M
mm3cl5GF58llhpzpU7zB0zpXNjhUJ9TqT1+ep2tc6RGQePAodLdT3WTwa/ZzVGUS
9anfFdMkkg6b5tn/O8mJt14kh07AGepPzZBM8rlH3WAgQ9BNEKvMgbHRkRh3OH4z
l71JdjVWAabeYATGDBIZPxFFBx2WFhgwWNzilLsO204oMqnozgui3aYdJNVYtVkb
tDzLgJpPNm0V2SMoZyiUdF0TadMBpgOY93/B2reFXmVrYczppM/4V/8lHJMC28Ha
HCoP2yVS1NGRV0EQt2F2ZvM/8XB6JE/G2GS7KSoapOslsxJik8lXmWshNgmA9LY=
=fKJ6
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users