[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing Elgamal signatures
Lutz Donnerhacke wrote:
> * Werner Koch wrote:
> > In the light of the recent GnuPG bug, where I accidently used the same
> > small sized k for signature creation as it is used for encrypting, I'd
> > very much like to drop the ElGamal signing ability all together from
> > OpenPGP. AFAIK, GnuPG is the only implementation with support for
> > these keys and by now the about 1100 known primary and subkeys should
> > have been revoked. Thus there won't be any interoperability problem
> > anymore.
> I'd like to oppose. ElGamal signatures are still useful, despite there is a
> charge of signatures with some algorithmic errors. I'd prefer a paragraph
> describing the problem and advicing to not use keys of this charge.
Thinking about the case for removing ElGamal from the
standard, here are the pluses that I see:
a. The purpose of the standard is to document the greater
good set of common and useful algorithms to which most
implementation should try and implement.
If there are O(1000) users of the ElGamal signature
algorithm, I'd say at first glance this does not qualify
as a major usage.
Also, if GnuPG is the *only* implementation of this,
then that would seem to go against the spirit of the
"two implementations" rule. (Although, not breached
in practice, as it is only a small part, I would guess.)
b. Removing it from the standard would only mean that other
implementations could then totally ignore it, instead of
choosing to ignore it. Also, removing it from the standard
does not mean it can't be used - it just means that it is
then a private algorithm. If it later on proves to be
of great use and other implementations adopt it, it can
always be added back into a future version, or written
into a informational draft.
c. Some change has to be made, because there is a bug. So
it might simply be a balance between removing it - easy? -
and writing in the bug-fixed-text - not so easy?
d. Less is much better. OpenPGP is already way too big and
complex, which slows its implementation and thus slows
its use, and its long term success.
Against the removal:
A. This is supposed to be very late in the game for the
production of the standard. There should be very minor
changes, if any.
On balance, there seems to be a good case for removing it
( I speak here without any knowledge of the technical aspects
of the algorithm, of course! Standard Dilbert comments
One thing I am not sure of - what is it useful for? In the
sense, does it do something that is highly prized and wanted?
That would perhaps be key in determining if removal is to
be warranted at this late stage...