There are actually two public keys?

[R.A. Hettinga]

I passed this on to Jon Callas. Here's what he came back with...

Cheers,
RAH
-------


Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

My apologies for top-posting, and please forward this on.

I'm going to agree slightly differently with David Shaw.

The reason for it is a notion of what's called "key hygiene," and
that's an important concept in RSA usage. That is the notion that one
should never sign with an encryption key, and never encrypt with a
signing key.

The reason for RSA is that every signature is a decryption, and every
encryption is a signature verification. The worry is that if you use
one key for both encrypting and signing, there's the possibility that
something exists that corresponds to that encryption as a signature.
And actually, such a thing must exist. In the hyperbole of the time,
there's the possibility that a murder confession exists that
corresponds to every encryption. I'm probably not explaining it as
well as others could, mostly because it's late as I write this, and it
always made me roll my eyes when I heard it.

The idea is arguably daft, but less so if you have weak hash
functions, perhaps. Nonetheless, it does make sense that since
encrypting and signing are the reverses of each other in RSA, you
should just make the policy decision to use a key *either* for
encrypting or signing, but not both.

That's the real reason for the dual key stuff in PGP 3, and thus
OpenPGP.

The discrete log stuff followed, but that was events catching up with
design. The DSA/Elgamal versions came very close to never being
shipped. Key hygiene was the first reason for the dual key structure.

	Jon

On May 17, 2009, at 4:32 PM, R.A. Hettinga wrote:

 >
 >
 > Begin forwarded message:
 >
 >> From: "Steven W. Orr" <steveo at syslang.net>
 >> Date: May 17, 2009 7:21:35 PM GMT-04:00
 >> To: GnuPG Users <gnupg-users at gnupg.org>
 >> Subject: Re: There are actually two public keys?
 >>
 >> On Saturday, May 16th 2009 at 23:40 -0000, quoth David Shaw:
 >>
 >> =>On May 16, 2009, at 9:14 PM, Lucio Capuani wrote:
 >> =>
 >> =>> > Can anyone explain why there is a difference between signing
 >> and
 >> =>> > encrypting keypairs, even for the same type (RSA)?
 >> =>>
 >> =>> As far as I've understood from the documentation, one of the
 >> reason
 >> =>> should be that it would be good practice to keep the signing
 >> key valid
 >> =>> indefinitely (thus, having one that never expires so old
 >> signatures
 >> =>> can be verified too) and renew the cryptographic one pretty
 >> often for
 >> =>> security reason. As before, I'd love to get confirmations or
 >> denials
 >> =>> of that ;), and if there's else about it.
 >> =>
 >> =>That's one of the reasons.  There were actually a good few
 >> reasons for the
 >> =>switch at the time (the "PGP 3" timeframe, which became the PGP
 >> 5.0 product).
 >> =>One reason was legal, and not technical.  RSA was still patented
 >> at the time,
 >> =>so that couldn't as easily be used.  DSA was chosen, but DSA
 >> can't encrypt,
 >> =>which pretty much required a multiple key (primary key + subkeys)
 >> solution.
 >> =>In addition, though, the multiple key solution was chosen for its
 >> flexibility,
 >> =>as you noted.  It is handy to be able to make multiple subkeys
 >> and regenerate
 >> =>them as needed.
 >> =>
 >> =>One thing the multiple subkey design makes possible is to keep
 >> the primary key
 >> =>offline altogether, and just use subkeys for all the day to day
 >> encryption and
 >> =>signing needs.  In this way of working, the primary key is only
 >> used for two
 >> =>purposes: to make new subkeys when that becomes necessary, and to
 >> sign other
 >> =>people's keys.  When it is not in use (i.e. most of the time),
 >> the primary key
 >> =>is stored on separate media (say, a CD-ROM or USB stick).  See the
 >> =>--export-secret-subkeys description in the GPG manual for more on
 >> this.
 >> =>
 >> =>Note, though, that if you want a single key for everything, you
 >> can still do
 >> =>that.  Generate yourself an RSA key using the --expert flag, and
 >> you can
 >> =>create a key that is capable of both encrypting and signing in a
 >> single key.
 >> =>It's unusual, and I don't recommend it, but GPG will happily use
 >> it.
 >>
 >> This is somewhat of a revelation to me, but I admit I'm a little
 >> new to
 >> this so  can't claim that it's a big revelation.
 >>
 >> I have read up on the theory of asymmetric crypto and I'm
 >> comfortable with
 >> that side of it, but I'd like to learn more on the technical side,
 >> especially as it pertains specifically to gpg. I have read the GPG
 >> and PGP
 >> book by Lucas and I also read the old PGP book by Garfinkel.
 >>
 >> I look at the output of gpg2 -K and I never actually saw anything
 >> that
 >> describes what the sec, uid and ssb rows mean.  I don't see a  
concise
 >> description of how and when the different data items are used to
 >> ref a key
 >> in a gpg command, e.g., when do I use a fingerprint? what's the
 >> proper
 >> thing to use when specifying an operation? It's sort of analogous to
 >> knowing how to create a complex definition in C and also being able
 >> to
 >> deref it. (Most programmers, don't usually get it right when they
 >> try to
 >> distinguish between an array of ptrs to ints vs a ptr to an array of
 >> ints.) How do I make use of multiple subkeys and when and why do I
 >> want to
 >> do this? Things like that.
 >>
 >> Any suggestions?
 >>
 >> --
 >> Time flies like the wind. Fruit flies like a banana. Stranger
 >> things have  .0.
 >> happened but none stranger than this. Does your driver's license
 >> say Organ ..0
 >> Donor?Black holes are where God divided by zero. Listen to me! We
 >> are all- 000
 >> individuals! What if this weren't a hypothetical question?
 >> steveo at syslang.net
 >>
 >> _______________________________________________
 >> Gnupg-users mailing list
 >> Gnupg-users at gnupg.org
 >> http://lists.gnupg.org/mailman/listinfo/gnupg-users
 >


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: </pipermail/attachments/20090518/55e6485f/attachment.pgp>