Re: backing up keys

[Peter Lebbing]

On 21/11/15 13:09, Peter Lebbing wrote:
> GnuPG outputs both a "Secret-Key Packet" as well as all UID's and
> binding signatures. It might output all certifications by others on the
> key as well; I'm going to write a separate mail about this.

Okay, it turns out it was a weird issue with my keyring. In fact, GnuPG
would seem to always output all certifications with
--export-secret-keys, and it does not honour --export-options
export-minimal or export-clean.

HTH,

Peter.

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

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

Re: backing up keys

[Peter Lebbing]

On 17/11/15 15:53, Andrew Gallagher wrote:
> No, there is no public key data embedded in the private key, but you can
> regenerate the important mathematical bits of the public key from the
> private key, and you can fill in your name, email etc. from memory. So
> it's not absolutely necessary - but it is convenient.

Let's look at this at three levels:

1) What GnuPG actually does when you invoke --export-secret-key

GnuPG outputs both a "Secret-Key Packet" as well as all UID's and
binding signatures. It might output all certifications by others on the
key as well; I'm going to write a separate mail about this.

2) What is in a "Secret-Key Packet"

> 5.5.1.3.  Secret-Key Packet (Tag 5)
> 
>A Secret-Key packet contains all the information that is found in a
>Public-Key packet, including the public-key material, but also
>includes the secret-key material after all the public-key fields.

3) What you can do with just the RSA elements p, q, e, and optionally d
and u.

You could create a key that allows you to decrypt your encrypted data,
although you might have to jump through some hoops regarding the
fingerprint.

To be able to recreate a key with the same fingerprint, you additionally
need to know when you created your key down to the very second. This
means that even if you can reproduce your UID from memory perfectly, any
signatures you issue will not be recognised by your peers and all
certifications on your UID are lost unless you have memorised the very
second the key was created.

All in all, I wonder: did someone tell you you could recreate your
public key using just the secret parts? Have you tried it yourself? As
far as decryption goes, I might agree, but when you say

> you can fill in your name, email etc. from memory

I think you're talking about regaining certifications from others, and
for that you really do need the creation timestamp down to the second.

> Brute forcing a password is always easier than brute forcing the key
> itself (otherwise you'd be typing in your entire private key by hand!),

This is an oversimplification. A symmetric key has no structure; it is
just data. RSA, on the other hand, has specific mathematical properties.
The numbers p and q are primes, which are spaced rather far apart on the
number line; all numbers in between would make valid symmetric keys, but
not valid primes for RSA. As a consequence, the information content in
the number is lower. In practice, OpenPGP private keys also include the
numbers d and u, which in fact can be computed from p and q (given e,
which is usually a constant), so hold no additional information content
at all.

It is claimed (though not universally) a 2048-bit RSA key is about as
strong as a 112-bit symmetric key. If we take this to be the truth, then
remembering a cryptographically random 19-character base64 string and
using it as a password for your secret key would balance the relative
strengths, and brute forcing the "passphrase" is just as hard as
brute-forcing the public key to reveal the secret key. 112 bits is a
full order of magnitude smaller than 2048 bits; there is no need to put
a passphrase with 2048 bits of randomness on your key to balance it out.

>> The gpg documentation[1] seems to indicate that paperkey works
>> better at backing up to paper. Is there some reason why?

An OpenPGP Secret Key Packet is identical to the public key packet, but
with the secret material appended to it. Paperkey just stores this
appendage, and uses the public key to reconstruct the secret key from
it. So when you print out the result of --export-secret-key, most of
what you are printing is actually the same stuff that is in the public
key, and you can just store the public key anywhere without stringent
security requirements; in fact, it's often available on the keyserver
network. Paperkey just stores the non-redundant bit, which is much smaller.

> That's fine if your OCR is perfect and your paper never gets folded or
> stained or torn, but ascii-armored data has no checksum or error
> correction so you may suddenly discover your paper backup is unusable.

There certainly is checksum data in OpenPGP packets, and the fact that
your key doesn't work is a checksum in and of itself. There is no error
correction, other than that it is mathematically possible to reconstruct
a prime from a slightly corrupted copy, and furthermore that the numbers
d and u can be recomputed when p and q are still intact, and that p can
be computed from the public key when q is intact, and vice versa. So
basically, all you need is either p or q to be intact. I'm not now going
to spend time thinking about whether u or d is actually enough already.

HTH,

Peter.

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

___
Gnupg-users mailing list
Gnupg-users@gnupg.org

Re: backing up keys

[Thomas Harning Jr.]

On Tue, Nov 17, 2015 at 9:58 AM Andrew Gallagher 
wrote:

> On 17/11/15 12:39, James wrote:
> > All,
> >
> > I'm new to GPG and am hoping to learn the ropes. Please forgive any
> > ignorant questions.
> >
> > (a) are there any recommended methods by which to back up your private
> > and public keys? I've seen some "paper" methods (paperkey) and some
> > GitHub gists that have taken the private key, broken it in several
> > pieces and used QR codes to back up. Which is better? Does it matter?
>
> "Better" really depends on your use case. Are you likely to forget your
> passphrase? Are you going to keep your USB backup drive in a floor safe?
> Are you expecting your home to be searched by the feds (or the mob)? I
> don't think there is One Correct Answer to that one...
>
> > (b) is your public key embedded in your private key? If you're not
> > actually uploading your private key to a keyserver (perhaps using the
> > key to secure data / files instead of email, thus no need for
> > keyserver), is it sufficient to back up the private key only, or
> > _must_ I back up both files?
>
> No, there is no public key data embedded in the private key, but you can
> regenerate the important mathematical bits of the public key from the
> private key, and you can fill in your name, email etc. from memory. So
> it's not absolutely necessary - but it is convenient.
>
> Of course, the backup of your public key does not need to be secure.
>
> > (c) Isn't the private key itself encrypted via AES256 when secured
> > with a passphrase? If so, assuming the passphrase is secure enough,
> > isn't it sufficient to upload this file to Dropbox, etc. for safe
> > keeping? Would appreciate both real-world and theoretical commentary
> > on this point.
>
> Brute forcing a password is always easier than brute forcing the key
> itself (otherwise you'd be typing in your entire private key by hand!),
> so if (when) dropbox do leak the key data you've given the Bad People a
> shortcut.
>
> > (d) as best I can tell, the --armor flag is used to dump the key to
> > ASCII. The gpg documentation[1] seems to indicate that paperkey works
> > better at backing up to paper. Is there some reason why? Can't we
> > simply run --armor, print the output and then use OCR to pull the key
> > back in in case of emergency?
>
> That's fine if your OCR is perfect and your paper never gets folded or
> stained or torn, but ascii-armored data has no checksum or error
> correction so you may suddenly discover your paper backup is unusable.
> And such discoveries usually happen at the worst moment. ;-)
>
> Andrew.
>
I wrote up a blog post a while back illustrating some backup mechanisms:
http://blog.eharning.us/2011/04/key-backup-for-paranoid.html

The PaperBack (http://ollydbg.de/Paperbak/) tool creates backups for data
that can span multiple sheets of paper and have a varying level of
redundancy and resolution.
Checking out a backup made quite a while ago, since the dots were quite
large, there wasn't much degradation in decoding ...barely activating
redundancy measures. It should do well even if you fold the paper as even
if you fold it in quarters, many of the squares should remain unmarred
I archived my paper backup inside a sealed document mailer - a nice help
against folding and useful marker if it were opened without my knowledge.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: backing up keys

[Robert J. Hansen]

> I'm new to GPG and am hoping to learn the ropes. Please forgive any
> ignorant questions.

Honest questions get honest and accurate answers.  Can't beat that for
customer service, can you?  :)

> (a) are there any recommended methods by which to back up your private
> and public keys?

Not really, although a fair number of people have written scripts and
tools to help automate the process.  If you were to ask (and tell people
what operating system you're running), you might get some responses.

> (b) is your public key embedded in your private key?

Yes.

> _must_ I back up both files?

You don't technically need to back up your public key, but it's a good
idea to back up your public keyring.  As you communicate more you'll
discover some of your correspondents don't have publicly-available keys
and they want to keep it that way.  If you lose their public key you'll
have to go back to acquiring their public key however you first got it,
which may be anywhere between an annoyance to an impossibility.

> (c) Isn't the private key itself encrypted via AES256 when secured
> with a passphrase? If so, assuming the passphrase is secure enough,
> isn't it sufficient to upload this file to Dropbox, etc. for safe
> keeping? Would appreciate both real-world and theoretical commentary
> on this point.

It depends.  If the bad guys get your encrypted private key they only
need one additional piece of data -- your passphrase -- to
catastrophically wreck your security posture.  If you're completely
confident the bad guys will never get your passphrase, then sure, post
your private key in the _New York Times_.

But maybe you shouldn't be completely confident.  Never underestimate
how foolish you can be when you've had a few glasses of wine and are
chatting up a pretty member-of-the-appropriate-sex.  :)

> (d) as best I can tell, the --armor flag is used to dump the key to
> ASCII. The gpg documentation[1] seems to indicate that paperkey works
> better at backing up to paper. Is there some reason why? Can't we
> simply run --armor, print the output and then use OCR to pull the key
> back in in case of emergency?

paperkey saves you a lot of paper by stripping out everything from the
key except what's absolutely necessary.  This also has the effect of
making the backup more reliable.  If you were to print out a full dump
of my entire private key, for instance, it would be hundreds of pages
long -- there are a couple of JPEG images attached to it.  An error on
page #67 could have catastrophic consequences for restoring from backup.

With paperkey, it gets reduced down to one single page of 8x11 paper.
It's easier to store, easier to handle, and easier to restore from backup.

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

Re: backing up keys

[Pete Stephenson]

On 11/17/2015 1:39 PM, James wrote:
> All,
> 
> I'm new to GPG and am hoping to learn the ropes. Please forgive any
> ignorant questions.

No need to apologize: that's how we all learn.

> (a) are there any recommended methods by which to back up your private
> and public keys? I've seen some "paper" methods (paperkey) and some
> GitHub gists that have taken the private key, broken it in several
> pieces and used QR codes to back up. Which is better? Does it matter?

In addition to the security of your backups, one of your concerns should
be "How easily can I recover the key?"

If the procedure is complex, error-prone, and/or relies on the
availability of certain software that might not be available, it may be
less likely to work in the future.

Also, as Andrew says, what's your use case? Protecting your backed-up
private keys from you being forgetful or a destructive event like a
house fire or flood is different from protecting your keys from active
adversaries backed by force of law (e.g. feds with search warrants).

Using myself as an example, my two primary keys are each backed up to a
set containing:

1. Two CD-Rs from different manufacturers (for reliability).
2. Two USB flash drives from different manufacturers.
3. A Paperkey-produced printout.
4. A printout that consists of the ASCII-armored private key printed in
an OCR-friendly font. Additionally, each printout contains a QR code of
each line of the ASCII-armored private key so I can easily scan each
line without having to manually type everything in.

Obviously, recovering the key from #1 or #2 is the easiest, while #3 and
#4 are for last-resort recovery.

For my RSA primary key, I also keep a copy of the primary key on an
OpenPGP Smartcard which is kept with the set.

For each key, I make two such sets: one set stays at home in a locked
box, while the other is in a safe deposit box in a bank thousands of
miles away near my in-laws.

Additionally, I store printouts of revocation certs for those keys.
Since I have the private keys backed up, they shouldn't be necessary,
but you never know.

Overkill? Perhaps, but I've lost private keys in the past and it's a
pain. My main concerns are loss/destruction of the keys and electronic
compromise: thieves are more likely to care about my TV and shiny
computer rather than my PGP keys, and the authorities are unlikely to
care enough about me to seize the keys from my home or the bank vault
(even if they did get them, they'd need to crack the passphrase). Your
mileage may vary.

What if you can't recall the passphrase? You may have the encrypted
private key available from your backups, but if you don't have the
passphrase it won't do you much good.

Here's a few ideas for what you could do:
1. Split your passphrase up using something like Shamir's Secret Sharing
(a handy tool for accomplishing this is
http://point-at-infinity.org//) -- you can keep some shares for
yourself and give others to friends for safekeeping.

Shamir's Secret Sharing allows you to set a threshold for the number of
shares needed to recover the secret. For example, you could generate ten
shares and require three to recover the passphrase. You keep three
shares for yourself (so you can recover the passphrase any time you
want) and give seven to friends. If your house burns down and you lose
your shares, you'd just need to ask any three of those friends to give
you their share and you're good to go.

Any adversary that has fewer shares than the threshold (e.g. if they
only have two shares) gains no insight into your passphrase, which is
useful for security.

2. Print out your passphrase and store it with the backup set. While
handy, this has the disadvantage of also revealing your passphrase to
anyone who has access to the backup set (e.g. a thief), though at that
point you probably have bigger problems like bad guys breaking into a
bank vault or your home.

3. Backup the private key with no passphrase. This is the easiest, but
also the most risky: anyone who gets your key is able to use it without
needing the passphrase.

> (b) is your public key embedded in your private key? If you're not
> actually uploading your private key to a keyserver (perhaps using the
> key to secure data / files instead of email, thus no need for
> keyserver), is it sufficient to back up the private key only, or
> _must_ I back up both files?

For clarity, the private key is *never* sent to a keyserver, only the
public key.

The private key and public key are mathematically related: if you have
the private key, GnuPG can automatically generate the public key. The
reverse, of course, is not true.

Put a different way, it can be handy to backup the public key, but it's
by no means necessary.

> (c) Isn't the private key itself encrypted via AES256 when secured
> with a passphrase? If so, assuming the passphrase is secure enough,
> isn't it sufficient to upload this file to Dropbox, etc. for safe
> keeping? Would appreciate both real-world and theoretical com

Re: backing up keys

[Andrew Gallagher]

On 17/11/15 12:39, James wrote:
> All,
> 
> I'm new to GPG and am hoping to learn the ropes. Please forgive any
> ignorant questions.
> 
> (a) are there any recommended methods by which to back up your private
> and public keys? I've seen some "paper" methods (paperkey) and some
> GitHub gists that have taken the private key, broken it in several
> pieces and used QR codes to back up. Which is better? Does it matter?

"Better" really depends on your use case. Are you likely to forget your
passphrase? Are you going to keep your USB backup drive in a floor safe?
Are you expecting your home to be searched by the feds (or the mob)? I
don't think there is One Correct Answer to that one...

> (b) is your public key embedded in your private key? If you're not
> actually uploading your private key to a keyserver (perhaps using the
> key to secure data / files instead of email, thus no need for
> keyserver), is it sufficient to back up the private key only, or
> _must_ I back up both files?

No, there is no public key data embedded in the private key, but you can
regenerate the important mathematical bits of the public key from the
private key, and you can fill in your name, email etc. from memory. So
it's not absolutely necessary - but it is convenient.

Of course, the backup of your public key does not need to be secure.

> (c) Isn't the private key itself encrypted via AES256 when secured
> with a passphrase? If so, assuming the passphrase is secure enough,
> isn't it sufficient to upload this file to Dropbox, etc. for safe
> keeping? Would appreciate both real-world and theoretical commentary
> on this point.

Brute forcing a password is always easier than brute forcing the key
itself (otherwise you'd be typing in your entire private key by hand!),
so if (when) dropbox do leak the key data you've given the Bad People a
shortcut.

> (d) as best I can tell, the --armor flag is used to dump the key to
> ASCII. The gpg documentation[1] seems to indicate that paperkey works
> better at backing up to paper. Is there some reason why? Can't we
> simply run --armor, print the output and then use OCR to pull the key
> back in in case of emergency?

That's fine if your OCR is perfect and your paper never gets folded or
stained or torn, but ascii-armored data has no checksum or error
correction so you may suddenly discover your paper backup is unusable.
And such discoveries usually happen at the worst moment. ;-)

Andrew.




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

backing up keys

[James]

All,

I'm new to GPG and am hoping to learn the ropes. Please forgive any
ignorant questions.

(a) are there any recommended methods by which to back up your private
and public keys? I've seen some "paper" methods (paperkey) and some
GitHub gists that have taken the private key, broken it in several
pieces and used QR codes to back up. Which is better? Does it matter?

(b) is your public key embedded in your private key? If you're not
actually uploading your private key to a keyserver (perhaps using the
key to secure data / files instead of email, thus no need for
keyserver), is it sufficient to back up the private key only, or
_must_ I back up both files?

(c) Isn't the private key itself encrypted via AES256 when secured
with a passphrase? If so, assuming the passphrase is secure enough,
isn't it sufficient to upload this file to Dropbox, etc. for safe
keeping? Would appreciate both real-world and theoretical commentary
on this point.

(d) as best I can tell, the --armor flag is used to dump the key to
ASCII. The gpg documentation[1] seems to indicate that paperkey works
better at backing up to paper. Is there some reason why? Can't we
simply run --armor, print the output and then use OCR to pull the key
back in in case of emergency?

Thoughts, ideas and real world experience on securely handling backups
of your sensitive GPG data would be _greatly_ appreciated!

James

1 
https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html

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

Re: backing up keys etc

[Faramir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lawrence Chin escribió:

> (1) It turns out that I got a revocation certificate made long time ago
> for the current key I'm using (8e758d5f) with the file name
> "[EMAIL PROTECTED] (0x8e758d5f) rev.asc" and saved on a CD. So, if I
> need to revoke this public key in the future, I just upload it to the
> keyserver?

  IIRC, you would need to import the certificate to your keyring, and
then upload the key to the keyserver... once you have done that, there
is no coming back... And I think if you do that, you will revoke the
whole key, with all its UID... the only time I imported a revocation
certificate, the key just had one UID, so I am not 100% sure about that.
And it was very easy to import it (indeed, I didn't intend to do it).


> (2) So I used OpenPGP key management, "file" -> "export key to file" to
...
> file consists of a public key block and a private key block. Now, if my
> computer ever crushes and I have to start everything over again, like
> downloading GNUPG and Enigmail again, do I just upload these 4 asc files
> and thus regain my keys again? Is this what is known as "back up"?

  Not upload, you need to import these files to your keyring... it is
easy to do. And yes, that is the meaning of "backup"... a backup is a
file or set of files, that allow you to restore the info to the state is
was before the disaster. Of course, if you modify one of your keys, you
need to export that key again, since the backed up file would not
contain the modification...


> (3) So I generated a revocation certificate for the older, first
> experimental key for this kurtc account of mine, which I never seemed to
> have uploaded to a keyserver. Here is the log:
...
> c:\Program Files\GNU\GnuPG>
> ---
> I typed in the correct passphrase at my third try. Now, where can I find
> this revocation certificate? I don't even know the file name!!!

  Good question... I think it should be in the same folder where your
backup key files were exported... and the name should be something like
the one you showed us in the question n°1, something like "email address
(keyID number) rev.asc". If it is not there, it could be at C:\Documents
and Settings\YourWindowsUserName\  or maybe in the GnuPG folder, since
you was working at that folder when you generated the rev certificate.

  By the way, I use Enigmail's Key Manager to generate easily the rev
certificates. Also, if you want to revoke a key which you still control
(I mean, you have the key, and you remember the passphrase), you don't
need to use the revocation certificate, you can revoke the key using
Enigmail's Key Manager, or by using GnuPG command line, or using
GPGshell if you have installed it... the revocation certificate can be
used to revoke the keys even if you forgot the passphrase... so please
keep it out from reach of children ;)

> Hopefully soon I'll get out of my newbie status and become able to help
> someone too!

  Yes, maybe we can answer the easy question, and leave the hard ones to
the experts...

  Best Regards
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJI3ulaAAoJEMV4f6PvczxAgd4IAJWNDJs+sfhfQWxQHgoDjw7C
ybdOfpYwP2jxK3x8pl3MrvYk6ghIzBBwIe4lYoVWtboUfu7F5Vu00HaYUwL3PMQo
yjygpXY8vZd6u6gnFoInCup9xJCw5jmLXH7KNvwcSWRVm9LHhu9IhFpx+qWZOXB3
EEBhXBospRwPYzJF0YY6/zDtFIu+a9pEwclM3FhMo/G/DXeJvbX92KfOAzghpYjH
iBjjik7gg3ky47b92zaqTvldjl7MQVM/9ekxkohiPXTOgAaiC5OPlt8qDDoPHfks
yhLKHEVQEMKjmmf49BROYfl04TRb3vIefcxSPPgyu0M2hflHDk74fG3HGh4/ZeQ=
=mloW
-END PGP SIGNATURE-

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

backing up keys etc

[Lawrence Chin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Okay, thanks for the excellent help, Faramir and Kara. Let me see if I
got this right.

(1) It turns out that I got a revocation certificate made long time ago
for the current key I'm using (8e758d5f) with the file name
"[EMAIL PROTECTED] (0x8e758d5f) rev.asc" and saved on a CD. So, if I
need to revoke this public key in the future, I just upload it to the
keyserver?

(2) So I used OpenPGP key management, "file" -> "export key to file" to
export both the public and secret part of all my 4 keys to the same CD.
When I opened the asc file of each of these 4 keys, I can see that each
file consists of a public key block and a private key block. Now, if my
computer ever crushes and I have to start everything over again, like
downloading GNUPG and Enigmail again, do I just upload these 4 asc files
and thus regain my keys again? Is this what is known as "back up"?

(3) So I generated a revocation certificate for the older, first
experimental key for this kurtc account of mine, which I never seemed to
have uploaded to a keyserver. Here is the log:

- 
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\ms paradise.msparadise-PC>cd c:\program files\gnu\gnupg

c:\Program Files\GNU\GnuPG>gpg --gen-revoke 0x480a7928

sec  1024D/480A7928 2008-06-04 kurtc1972 <[EMAIL PROTECTED]>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 2
Enter an optional description; end it with an empty line:
> first testing key for this dummie email account of mine for learning gpg
>
Reason for revocation: Key is superseded
first testing key for this dummie email account of mine for learning gpg
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "kurtc1972 <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 480A7928, created 2008-06-04

gpg: Invalid passphrase; please try again ...

You need a passphrase to unlock the secret key for
user: "kurtc1972 <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 480A7928, created 2008-06-04

gpg: Invalid passphrase; please try again ...

You need a passphrase to unlock the secret key for
user: "kurtc1972 <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 480A7928, created 2008-06-04


c:\Program Files\GNU\GnuPG>
- ---
I typed in the correct passphrase at my third try. Now, where can I find
this revocation certificate? I don't even know the file name!!!

Thanks!!

Hopefully soon I'll get out of my newbie status and become able to help
someone too!

Lawrence

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkje0hcACgkQE7PX/Y51jV8NFQCfaUjc24xUkV6tog/WxqjH4UZ0
opQAoNN7J2oVZu3PEpPrHiVycEVOSq7F
=HkhB
-END PGP SIGNATURE-

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