David Sternlight <david(_at_)sternlight(_dot_)com> writes:
This is a bogus explanation for two reasons:
1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most
versions of pay PGP 5.0.
2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see
below). Yet :
a. MD5 is a hash function not an encryption algorithm.
b. There have been no practical cases of signature spoofing with MD5--it
hasn't been broken.
I agree, in the general case it has not. I'll discuss a better
user migration path below.
c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0
It is possible that Will was talking about the fingerprint spoofing
attack, which you are probably aware of. This flaw is nothing to do
with MD5 or RSA per se, but more to do with a flaw introduced in the
way that the fingerprint is calculated in pgp2.x.
Here's a key with a spoofed fingerprint:
Type Bits/KeyID Date User ID
pub 704/977EE465 1997/06/08 Adam Back <spoofed fingerprint DO NOT USE>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzObE60AAAECwJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA
TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW
65d+5GUBSJ7iDg8utJslk8EUh7N3zF12fHn7mFtGTUrpSl9F5C47Kci4nVVqSmcT
tCpBZGFtIEJhY2sgPHNwb29mZWQgZmluZ2VycHJpbnQgRE8gTk9UIFVTRT6JAG0D
BRAzmxOtOgSW65d+5GUBAQ27ArwOTveQTs0kjzBEMa09yWFs5+jNjv5tzSCngzXO
bRzvwhTwWz4voR3ov2o0bGTYZF1biKRKeKqZzHb4Oq4XhD4TADdlmsxA5gQgbYFN
5K+tbgWEDQD53KFv
=rlth
-----END PGP PUBLIC KEY BLOCK-----
It has the same fingerprint as my low security 1024 bit key attached
below.
However it does not have the same keyid. It is fairly unlikely that
pgp2.x key generation code would generate a key for which it is
possible to spoof both keyid and fingerprint at the same time.
Therefore a simple solution is to always consider the keyid part of
the fingerprint information, say like this:
556a4a67/18b8a0659d381483615ae6ac918b9e57
This would then be a user education task. Many people do include the
keyid in their signatures along with fingerprints already. pgp2.x
already displays the keyid at the same time.
(I downloaded the 25Mb key ring and searched all the keys to see if
there was anyone a double keyid and fingerprint spoof was possible for
-- there was not. It was something like a 25% chance I think I
calculated given the size of the key database.)
In short, PGP Inc. has taken the weakest and most vulnerable sector--the
free users, and shoved it to them in an authoritarian "big brother" way.
(Ironic, that, given many PGP' staffers' and the founder's ideological
pretensions). Since that is the "huge" RSA-key user base (check the MIT and
linked international servers) PGP is waving around to justify itself both
in press releases and to the IETF, a more egregious case of biting the hand
that indirectly feeds one is hard to imagine.
When you subscribe to this list (ietf-open-pgp), it says this:
: PGP has become a very popular method for establishing trust between
: internet users for securing communications. In order to grow the
: installed-base of over 4 million users, ...
So yes, PGP uses the freely installed base in it's figures. RSADSI
used to be fond of this also (using freeware PGP installed base in
their figures of RSA users).
Brave talk, but if you had any integrity you would have explained
any concerns and left it up to users by preserving all options--not
crammed it down the free user's throats.
I think that unencumbered algorithms are a good thing, however I think
the method of "encouraging" migration to DSS/EG algorithms has largely
backfired. I did a survey of pgp users, which I'll colate shortly,
and several commented that they scrapped 5.0 and went back to 2.x when
they discovered the various compatibility problems (eg. not being able
to generate RSA keys).
This is especially underhanded-seeming since Free PGP 5.0 uses RSAREF,
which can generate RSA keys, carries no fees, and is not in legal dispute
as between PGP Inc. and RSADSI.
Yes, I agree with this... there is no legal reason not to include RSA
keygen in freeware.. it already includes RSA encrypt decrypt, and
RSAREF allows this anyway.
Now the discussion of a better migration path. It seems to me that a
nice thing to do would be to generate two keys at key gen time: an RSA
key and an DSS/EG pair. The software could then cross authenticate
the keys (thus retaining the web of trust if the RSA key was an old
one.) The software could then use DSS/EG keys when talking to other
pgp5 users (as determined by their public key, or a feature such as a
comment field embedded in a 2.x message which would not upset a pgp2.x
implementation), and revert to RSA when the user could not cope with
5.x DSS/EG keys. Largely transparent interoperability on all versions
would I suspect paradoxically have meant many more people made the
switch.
Adam
The real key the above spoofed key is a fingerprint spoof of:
Type Bits/KeyID Date User ID
pub 1024/556A4A67 1993/06/08 Adam Back
<aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAiwUXUEAAAEEAJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA
TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW
65d+5GWe4g4PLrSbJZPBFIezd8xddnx5+5hbRk1K6UpfReQuOynIuJ1VakpnAAUT
tBxBZGFtIEJhY2sgPGFiYUBkY3MuZXguYWMudWs+iQCVAwUQMiDfwUZRiTErSPb1
AQF/yAP8D1X2eAhXSc0P/X7lCHyBhWCl3pxa6oyGxFBOmUeOGfYna8CpJeMiTmZm
akRWDYmJUiXscQUfd9qRv8eAeOtbvM87olSjm56Dlh4gYJFZRxZ6IhHlFJx3mPmp
q9PnL+pSC41IIheRBJFzpKGD3LW9+VQwRAx9bXFJYyOFpx7vGJqJAJUCBRAwLhaV
fjuD7tLfgD0BAYnfA/0XByiiqDX/cxgWt9syiobJ0TrTKloJcEgzxnKmqHH7rhqn
wWGQA2pbWPGW1AwLtkeE+JYyk21YQZZxYWerK3JUi8a/ye4EaaJSs8mcw9YCwdPC
Xa0nlalh09/FBEt83l5auNbw+zl9AcrOIGsTQcAr0Vy5nnV9IEfi6WZ3/aQ734kB
FQMFEC/gRoaxVzBJFqEkZQEBEXcIAI6z9nUinIomouzB/3v1Fu9+kLOLiva+7Mp1
8UT40FXvHSabXe/cSV1//lnlYHJnfpJCPFSEjGox1pVBp9pLmiJBmubLfUrojIAn
FDB081n6kB0B4BKb2rUiNghvT4CzpBZ149g/2NGscRIeQOCYkA2cBxT44v2luuqN
3Ahg9bWu+kjnxUKIK9Da/8D0ur5HiinBDevPiVf3/uoOdZ8F7alxqitBcC5ctIYR
tr8fgdQq8is6dbeNxDMraV5vEpEN27AU4xOetymdFUufbU1K6Riw5TVZni9qXAgU
ZS3zyFw7wqJ/SWILMWp+99ss921b+GpL+/m6S4j7LTXvFvcfy9aJAJUDBRAv2A0p
Kci4nVVqSmcBAcfoA/9Pt3BeJ3TdTtQzb9DNT7LoXiQesYG68lzIl7BZsRvXoi2Q
yeCPNc/juTGBnKBHgxZezJCW8TaKdJjNEncv7p+1o+9fwmy9UKWXskh6N+Y0ZlhJ
bD0T+8+L+Wxpr6k3dao/GfOnCvw8vpvzDV9lnjtqe2B1mU5eAY76FFtZXvM9xw==
=xN9o
-----END PGP PUBLIC KEY BLOCK-----