[ale] PGP / GPG Keysigning party... Upload your key now!

[Michael H. Warfield]

I'm going to add the ALE list back on to the cc here because this is a
very good, very valid, question that I think everyone should understand
as a part of PGP/GPG and the way things have evolved.

On Sun, 2011-11-20 at 16:16 -0500, Scott Castaline wrote: 
> On 11/19/2011 08:03 PM, Michael H. Warfield wrote:
> > On Sat, 2011-11-19 at 19:05 -0500, Scott Castaline wrote:
> >> Unfortunately I missed this month's meeting, so I do not have the
> >> details for the keysigning party. It was sort of up in the air before
> >> the last meeting, is it still going to be at the usual meeting
> >> place/time, or somewhere else and some other time?
> > No, it won't be at the usual place.  Others are making arrangements and
> > I heard references to December 8.  Others will have to post the details.
> > I'm just dealing with the keyring and the some of the operational
> > issues.
> >
> > Mike
> I'm in the process of reading up on PGP key generation and have noticed 
> that I have both pgp and pgp2. Which one should I be using? Can I safely 
> assume that pgp2 will be able to deal with a pgp generated key?

That is correct.  You should be good to go and I would recommend using
gpg anyways unless you know specifically what you want gpg2 to do for
you that gpg does not.  Trust me here, if you had to ask the question,
then it doesn't matter and you can stick with gpg.  Version 2 of Gnupg
(gpg2) also supports S/Mime encryption, another IETF standard involving
SSL certs and what not.  But that has no impact on using it for PGP
operations and functions.

> What 
> about the other way, would someone who does not have pgp2 on their 
> system be able to process a key generated by pgp2?

Yes.  The are interoperable.  Basically, gpg2 is a rewrite of gpg that
has better integration for smartcards (which gpg does have) and plugin
modules and a variety of things.  But OpenPGP itself (which is what gpg
implements) is a standard (IETF RFC for OpenPGP) and has been for some
time.  Both are interoperable with reasonably recent versions of 
"real" PGP (Paul Zimmerman's Pretty Good Privacy), though earlier 2.x
era versions of the ancient PGP used the IDEA symmetrical algorithm for
some things which nobody supports any longer even though the patent on
Idea ran out ages ago.  The IDEA algorithm is still around and available
as a module but it's still not packaged by default.

> I have noticed that 
> pgp2 supports only 3 alogrithms for pubkey versus 5 for pgp, (now for 
> the possibly dumb question), why? Follows are the outputs for --version 
> of each:

> $ gpg --version
> gpg (GnuPG) 1.4.11
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

> Home: ~/.gnupg
> Supported algorithms:
> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
> Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
>          CAMELLIA192, CAMELLIA256
> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2

> gpg2 --version
> gpg (GnuPG) 2.0.18
> libgcrypt 1.5.0
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

> Home: ~/.gnupg
> Supported algorithms:
> Pubkey: RSA, ELG, DSA
> Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
>          CAMELLIA192, CAMELLIA256
> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2

Oh, that.  That's not what you think it is.  It's really just
notational.  It's really the same thing.

In the earlier era, the days of PGP 2.x through 4.x (pure PGP, real PGP,
pre GPG and pre OpenPG) you would have a a single RSA pair in a key that
was used for BOTH signing and for encryption.

If you download my legacy, df1dd471 with the command "gpg --recv-keys
df1dd471" and then do a verify on it by running "gpg -kvv df1dd471"
you'll see it has no subkeys.  That key is a type type 3 key and is not
longer considered "secure" for encryption purposes.  I only maintain it
for signings because it was one of the keys published in the "dead trees
edition" of the web of trust years ago.  It was originally created under
PGP 2.3 back in 1994.  It's a "trophy" key for those who want a
signatures from a key that old.  I never sign ANYTHING any longer with
that key without also signing it with my more modern 674627ff 2048/R
key.

Modern PGP keys, beginning with the PGP version 4.x (IIRC), began
supporting subkeys for signing and encryption.  So, for RSA, you could
have an RSA key for encryption, an RSA key for signing, or an RSA key
that supported both (discouraged).  DSA is the Digital Signing Algorithm
(aka DSS - Digital Signature Standard) and is "signing only" by the
design of the algorithm, anyways (earlier versions of PGP did not
support DSA or any form of elliptic curve, EC, cryptography).  ELG is
ElGamal EC cryptography (ECC) and is the encryption half of the DSA
keys.  So that gave you 5.  RSA, RSA-E (encryption only), RSA-S
(signatures only) for the "RSA based" keys, ELG-E, and DSA for the "DSS
based" keys.  Now, gpg2 has basically collapsed RSA-E and RSA-S into
simply RSA and it's all controlled by an attribute flag in the key's
meta data for the subkeys anyways.  That then reduces the 5 to 3.  RSA,
which can be used for both signing and encryption and maybe be in
subkeys for either signing or encryption or both, and Elgamal for
encryption and DSA for signing in the EC keys.  So really, it's still
the same, it's just the notation that has changed and you really only
have two choices of keys - RSA (signing and encryption) or DSA/DSS.

Now, as to the obvious NEXT question that comes up "which is better, RSA
or DSA" the answer has varied over the years...  After a number of
cracks of RSA challenge keys, 1024 bit RSA keys were no longer
considered to be "strongly" secure and RSA fell out of favor for a
number of years in favor of ECC.  ECC had some advantages.  Some have
argued that you get stronger cryptography from ECC than RSA for the same
number of key bits.  Arguments over performance have danced back and
forth.

Recently, the pendulum of opinion has swung back again in favor of RSA,
after some theoretical papers were published about potential weaknesses
in DSA (or was it ElGamal - I forget - they're related anyways).  So,
now, 2048 bit RSA is considered to be the "gold standard" and is the
current default for gpg and gpg2.  I also highly recommend RSA over DSA
for things like ssh keys.  The math is elegant and simple and has stood
the test of time (so far).  Anyone with DSA/DSS keys - that's still
fine.  They're not broken, they're just kinda not as popular these days
and there are good arguments on both sides of that fence.

Another argument for RSA keys is that RSA is supported by a number of
security tokens and cards such as crypto smartcards and USB keys.  I
have not run into any that support DSA or Elgamal.  The Aladdin eTokens
support up to 2048 bit RSA encryption where the private keys are on the
token and you can NOT copy them off.  Good stuff.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20111120/bcdbe21a/attachment.bin