[Cryptography] More efficient and just as secure to sign message hash using Ed25519?

Viktor Dukhovni cryptography at dukhovni.org
Mon Aug 3 20:54:10 EDT 2015


On Mon, Aug 03, 2015 at 08:11:52PM -0400, Allen wrote:

> Would hashing twice with MD5 be the best way to prevent that attack, or
> might it be better to use a stronger hash function?  See also my earlier
> comment: "I could probably find a way to use those CPU cycles that would
> yield a better payoff (using a stronger curve or a more complicated hash
> function perhaps?)."

If what the curve is signing is the message hash, a stronger curve
cant't help.  There is merit in constructs that rely on fewer
unproven assumptions about the underlying primitives.

Few of us expect SHA2-256 to SHAKE-256 to fail soon.  Attacking
them may even lie beyond human ingenuity, but history has been on
the side of the pessimists.

In many applications the message size is bounded by protocol
constraints, and hashing twice is not a significant bottleneck.

A typical use might be signing the parameters for an ephemeral key
exchange, where the message size is quite small.  Another is signing
X.509 certificates.  In neither case is it onerous to hash twice.

The real obstacle is existing combined digest+sign IUF (initialize,
update, final) APIs.  If one is to plug the new signatures into a
generic framework, the new algorithm would have to buffer the data.

In some cases libraries also offer an all-in-one primitive that
combines I, U and F, and that would be more efficient with the full
message already in memory, by avoiding memory allocation and copying
overhead.

So the reason why the proposal might get traction is not the modest
CPU cost, but API impedance mismatch.  We've learned to expect
signing APIs to turn meat into sausage in a single pass, and changing
the model is difficult.

The proposal seems sound on its merits, but may be too difficult
to adopt.  Thus CFRG seems to have decided to preserve IUF, but
internally the signature algorithm may still take H(M) as the
message, and sign that more securely (yes even though it is too
late).  Separately, new interfaces might be made available for
conservative designs that choose to bypass IUF and not bolt the
door after the horse has left the barn.

-- 
	Viktor.


More information about the cryptography mailing list