Where did Trust_ go?
Werner Koch
wk at isil.d.shuttle.de
Thu Apr 8 07:37:08 CEST 1999
RavenZ <ravenz at gmx.net> writes:
> 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
Well, I think these 3000 bits are an assumption which are quite high
considering the current algorithms available to solve a dicrete
logarithm - but yes, after whitespread use uf RSA there was a big
progress factoring algorithms.
The encryption key depends on the signature key (unless you always
check the fingerprint of the encryption subkey) and therefor DSA is
the weakest link. The subkeys are easy to replace and if you have
really high needs to keep something secure for al long time you won't
use publiuc key cryptography anyway but use two conventional
algorithms in turn (so if one gets broken, the other counts as your
safety web)
> cryptography. They also slow everything down and burden the key servers
> and everyone's keyrings, as well as cause interoperability problems
Right. Not everyone has a 786-900Mhz - there are even many 386 out in
countries where cryptography may even be needed to protect lives.
> 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
I think this is a very good argument.
> Also, larger DSA keys don't contribute anything unless the hash grows
> bigger with it. That requires selecting a good well-designed bigger hash
Rumors are that we will have a larger hash algorithm in some time and
then we can extend DSA. Note, that there was a debate on coderpunks,
what is the length of an DSA/ElGamal key and some folks argued that
DSA is a 160 bit algorithm and not a 1024 (or whatever) and that the
larger numbers are just used for marketing reasons :-)
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013
More information about the Gnupg-devel
mailing list