On Tue, 2 Jun 1998, Philip Zimmermann wrote:
No, "PGP" is not playing a game. These were my own remarks, not PGP's.
I didn't know which implementation got it wrong. I knew that we had it
wrong in our experimental code (that's why it was experimental, and
ifdef'ed out), and I knew that Jon had told me that someone else did too,
but I didn't remember who it was. I guess "they" got it wrong because we
got it wrong first, and they used our ifdef'ed code as a base. Maybe
"they" is you. I'm sorry if that sounded insulting in my posting; I
didn't mean it that way, and I didn't know who it was. I typed those
remarks at home in the wee hours of the A.M., without the benefit of
having Jon Callas around to ask him for details.
It is best to avoid hearsay even at wee hours of the morning. The only
defect that I know of is given in the link on El Gamal signatures from
http://www.bell-labs.com/user/bleichen/bib.html
Which is also covered briefly in the Handbook of Applied Cryptography.
I think I fixed my version to take care of this security hole before the
OpenPGP WG was formed. I don't know of any other security flaw in
ElGamal, but don't subscribe to abstract mathematical journals.
The original PGP published source contained disabled support for ElGamal
signatures and was broken. This code should have been removed, though I
may have been the only one to enable it.
We should not have let it out. It was experimental. Hal thought that
the #ifdef around it would be enough. It keeps the compiler away from
it, and he thought that was enough to keep people away from it, too.
It was and is. I think I was the only one to actually enable them. I
also enabled DSA/RIPEMD and such.
They will be subjected to Haval, Tiger, DES/SK (when it is available),
Blowfish, Safer/SK-128, MD2, EC (in whatever form), on the same basis as
ElGamal. Why include all these, but not ElGamal?
I don't think we should include these either, but I didn't want to make a
fuss over them, in the interest of making people happy.
These were less controversial than ElGamal. There is little use for extra
algorithms which provide similar function. Suggesting that we drop any of
these would have caused less furor.
This late in the game, I would agree to changing the MAY to a SHOULD NOT
for ElGamal. I would even be willing to disable it by default in my code
in the same way that PGP 5.0 disabled support (after fixing it if mine is
the errant implementation). And I think the other implementors may agree
to do the same thing and do a moratorium on "enabled ElGamal" until the
next spec is released and we can then either delete it or place caveats
or come up with a way of extending DSA.
Maybe that would work, if we can keep ElGamal from entering the PGP PKI.
I would rather extend DSA as soon as we can find a suitable hash. But
let's not hold up the spec to do it. It will take a while to find a good
hash.
How about "Algorithms that are not 'MUST' or 'SHOULD' SHOULD NOT be
entered into the PGP PKI". This is perfectly reasonable - you wouldn't
want experimental algorithms widely published, nor keys that are rarely
implemented. Since ElGamal is MAY, keyservers SHOULD NOT accept them.
I think this addresses your concerns with the least disruption.
Maybe we could use the algorithm byte value that is used for experimental
algorithms. It would be nice to find a way to buy some more time without
holding up the spec, while limiting the uptake of ElGamal signatures.
I would like to keep it at 20. I can move it, but that number was created
for the specific reason.
--- reply to tzeruch - at - ceddec - dot - com ---