Where did Trust_ go?
ravenz at gmx.net
Wed Apr 7 23:36:11 CEST 1999
At 22:30 06.04.1999 +0200, you wrote:
>Werner Koch dixit:
>> Horacio <homega at vlc.servicom.es> writes:
>> > sec 2048 0xDDDC215A 1998-07-20 ---------- DSS Sign & Encrypt
>> ^^^^ ^^^
>> 2048 bit DSA key - strange. DSA is only defined for 512 to 1024 bit.
>> Who created this key?
>> > sub 8192 0x06E9D714 1998-07-20 ---------- Diffie-Hellman
>> IMHO this far away from any reality.
>Do you mean it's worthless? Well, I saw a few like this around ... it was
>created with some C-KT package (not sure ... I think it's a hack of PGP);
Get it at http://members.tripod.com/IRFaiad/
>they claimed much larger keys could be generated (I once tried, but it took
>far too long). There was also another program ... pgp2.6a or so, which had
>similar claims. I recall the person's name is Peter Wilson ...
>I thought the reason behind not creating longer keys was that they not only
>take long in being generated, but they too take long on
>encryption/decryption processes. But they could be generated.
I always thought longer keys provide better security since the keys are harder
to crack. But the readme of "PGP 6.0.2ckt" contains a letter from Phil
Zimmermann that confuses me. See for yourself:
There is no advantage for using the keys larger than about 3000 bits.
The 128-bit session keys have the same work factor to break as a 3000
bit RSA or DH key. Therefore, the larger keys contribute nothing to
security, and, in my opinion, spread superstition and ignorance about
cryptography. They also slow everything down and burden the key servers
and everyone's keyrings, as well as cause interoperability problems
with present and future releases of PGP. Perhaps even more importantly,
they also undermine other people's faith in their own keys that are of
appropriate size. While it may have been well-intentioned, this massive
expansion of key size is a disservice to the PGP community.
Also, larger DSA keys don't contribute anything unless the hash grows
bigger with it. That requires selecting a good well-designed bigger hash
that has been specifically designed to have the full work factor for
breaking it. Using two SHA1 hashes in that manner has not been adequately
shown to achieve this result.
Anyone with a sophisticated understanding of cryptography would not make
the keys bigger this way.
Experimental code that we put into PGP during its development should not be
used. It was protected with conditional compilation flags and should never
have been revealed to uninformed users who decide to perform a "public
service" by enabling the code and releasing it. This is part of the reason
why we ask people not to release code changes on their own, but to send them
to us, so that we may incorporate some of them (if they seem like good ideas)
into our next product release. That is how PGP enhancements from the user
community have always been managed since PGP source code was released in
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0b16
-----END PGP SIGNATURE-----
More information about the Gnupg-devel