Questions about generating keys

[Robert J. Hansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Oskar L. wrote:
> That's good news. Can it also create them? But there are probably
> still many using older versions. I know some who refuse to update
> from 6.5.8.

Yes.

And yes, there are still people using the very old 6.5.8 codebase.
These people ought to be dragged out into the street and forcibly
introduced into the twenty-first century, but hey, that's just my opinion.

> Ok, so RSA isn't always significantly faster, as I thought it was. I
> had read somewhere that it was, (probably on this list) and my own
> testing with my 4GB backup files showed RSA to be notably faster.

Err--how?

When you're doing a signature, you're signing less than 1k of data with
RSA or DSA.  When you're encrypting a file, less than 1k of data is
being encrypted with RSA or Elgamal.

How does this test show any speed difference between the two?  The time
differential between RSA/DSA/Elgamal is statistical noise given the
much, much larger time spent reading the 4GB of data.

> - for signing DSA is faster, for verification RSA is faster, but
> there's not much of a difference.

I'd just keep the last clause.  "There's not much of a difference."

Timing of DSA versus RSA will depend heavily on everything from
processor load to disk I/O to the phase of the moon.  Generally
speaking, yes, the first two clauses are correct, but it's impossible to
say with specificity what will happen in your particular environment.

> - OpenPGP implementations must support DSA, but supporting RSA is
> optional, but both gpg and PGP support RSA, so there's not much of a
> differance.

Pretty much.

> - original DSA limited to 1024 bit keys and 160 bit hashes.

Yes.

> - DSA signatures are smaller.

Yes.

> - updated DSA, aka "DSA2", equal to RSA when it comes to the lenghts
> of keys and hashes.

Not really.  E.g., DSA2048 uses SHA256 as a hash algorithm.  But I can
use SHA512 with an RSA2048 key.  RSA keys offer the best selection of
hash algorithms, but this is mostly a canard.

> - Of PGP, only the newest version support DSA2 keys.

Newest versions, not version.  I think PGP 9.0 introduced DSA2, and
they're up to 9.5.

> - RSA has a hash firewall

Yes, but I am unconvinced that this is something an average user needs
to be concerned about.  (I'm concerned about it, but I freely admit to
being paranoid.)

> RSA still seems better to me, but not by as much as I previously
> thought.

What does this "better" mean?

Seriously.  You're arguing about whether Godzilla or Mechagodzilla is
more effective at flattening downtown Tokyo.  The answer doesn't matter.
 Whether it's Godzilla or Mechagodzilla, people are still going to run
for the hills.

Likewise, given the astronomical difficulty of attacking either RSA or
DSA, it's hard for me to say one is "better".  The instant an attacker
sees RSA or DSA, the attacker is going to give up trying to forge a
message by cryptanalytic means.

In a lot of ways, I think this is arguing over how many angels can dance
on the head of a pin.

> So they accepted RSA into the standard, while it was still restricted
> by patents, as long as it wasn't made the default?

You can have a perfectly OpenPGP-conformant application that treats RSA
messages as noise and silently discards them.

In RFC language, there are a few special keywords that are almost always
capitalized:

MUST: a conformant application is required to...
SHOULD: while not required for conformance, it is good if...
MAY: totally irrelevant to conformance, but worth considering...
NOT: invert the meaning of the preceding word.

DSA is a MUST algorithm, as are SHA-1 and 3DES.

RSA is a MAY algorithm.

> I took for granted that an open standard like OpenPGP would not have
> accepted any patented stuff into the standard

It didn't.  You can implement OpenPGP without paying anyone a dime in
patent royalties.

> If the IETF refused to make RSA the default, does that mean that the 
> people behind OpenPGP originally wanted it to be the default, but
> then had to change it to DSA?

The distinction between "the IETF" and "the people behind OpenPGP" is
not as big as you might think.

The IETF is fundamentally composed of a lot of people who are interested
in technology.  That's all.  Their working groups (WGs) are open to the
public.  Public participation on IETF mailing lists is heavily
encouraged.  I sit on the IETF OpenPGP mailing list just to track the
latest changes.

In Ye Olden Days, when Phil Z. was developing Classic PGP (PGP 2.6,
RFC1991), his attitude towards intellectual property was remarkably
cavalier.  It created an awful lot of problems for PGP 2.6, since
practically everything about it was patent-encumbered.  The patent
problems were one of the driving forces behind the development of a
next-generation PGP technology, which became OpenPGP (RFC2440).

- From the very earliest days of OpenPGP, there has been a strong
commitment to the total absence of patent-encumbered algorithms from MUSTs.

> I would not say that just because someone doesn't willingly make
> their address available to spammers makes them a believer in security
> through obscurity. Full disclosure is not a good strategy when it
> comes to personal information like e-mail addresses, credit card
> numbers etc.

I'm with John Clizbe on this one, although I'd use a different argument.

In the battle between armor and warhead, _always_ bet on the warhead.

Playing defensively and trying to make an email address invisible is
going to be an exercise in frustration.  They always get seen.  They
always get spammed.  Play defensively and you lose.

Whitelisting, graylisting, blacklisting, Bayesian filters, even lawsuits
if you're so inclined--those are all active measures which force the
spammers to adapt to your actions.  That gives you a measure of
initiative back.  You're no longer playing pure defensive.

If you like, I'll ask the antispam research group here at UI if they
think there's anything to be gained by omitting an email address from a key.

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

iFYEAREKAAYFAkbM+50ACgkQf2XByo0Cu7N03gDeJlx8PraZYkGURhaBeACc+yNm
iL74DXfbA9touADeLCaUxKN28EWvkc8Zzct3YhETW2lHj1xeubYUookBHAQBAQoA
BgUCRsz7nQAKCRC3APSC/q+BCS0zCADMTlLu4935o2rskJMEJHRiYVZL92ZSLM8E
Gat9thVt0wC+uj140cSynRj/yPvVHm9jbI0RRJQcokod9hBPys1iUGSV2md7Bxgm
ycWji7A87PR3lFTrUk/FuUzIbj4afnQn0EkChx27YJL3H1rAZ5X2AqH1lNY/WrLK
YqvDfVLBtEBSR+3i4XxIW7vD1j3ZXy89WeAvGTKnykv2aqJ1hqkhUArG5KI2Z2v7
OGVp6vec1l+LPxI/lutaTFTHh9g6dOPGxKu9NVMHaHeBgP5E5sacpxrwhDO1Rxn4
tXQpIlxuNhgmnw1pIUpHJHrrhUsTsuHEYSmA7A9kelse0WI0S4Ig
=LAPz
-----END PGP SIGNATURE-----