-----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----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users