Subject: [Cfrg] Signatures: curves/hashes by key vs. by invocation

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Aug 2015 16:09:51 +0300

The signatures have curve parameters and (possibly multiple) hash
parameters. Some of these seem unsafe to vary...

Curves: To me it seems like a bad idea to sign with arbitrary
curves (beyond just weak curves). Therefore, the private/public
keys should fix the curve used.

As why would anyone do this kind of signing is beyond me, but I
think using arbitrary curves was bought up as justification for
truncating hash in calculation of s instead of just using modulo
like most proposals do.

Hashes: There are potentially multiple hashes involved:
1) The hash used in derivation of r and such (usually the same as #2,
   but different one might be useful in "hostile" environments[1]).
2) The hash used in calculation of s (verifier has to calculate this).
3) The prehash (not all schemes have this).

Clearly #1 should be fixed by private key (it is internal to signer,
so no public key counterpart) or be derived somehow (ensuring it is
wide enough) from #2 (but it seems like bad idea to me to vary this).

#2 Should presumably be fixed by private and public key: If #2 can
vary but #1 stays constant, the private key can easily leak (by
"nonce" reuse, barring type of firewalling IIRC no proposal does).

#3 Might be per-signature if firewalled. But if it is not firewalled,
it isn't entierely clear if it is safe to mix different prehashes of
the same length (so mixing SHA-256 and SHA-384 is OK, but SHA-256 and
SHA3-256 isn't). And mixing up prehashed and non-prehashed modes is
especially dangerous (I think it was agl that pointed out an attack[2]).

[1] IIRC, no proposal explicitly considers that this hash might be
different from #2. That it might be useful to do so was brought up
IIRC by Hamburg.

[2] Contrary to some replies, the attack is of feasible complexity,
since you only need 2^k signatures, where k is the needed information,
which is presumably <<128 bits.

-Ilari

---

From: Dan Brown <[email-masked]>
Date: Fri, 7 Aug 2015 14:04:46 +0000

hash truncation is not aimed at supporting arbitrary curves.

Rather it is a(n extra) countermeasure to Vaudenay's attack (in which some authority has chosen the curve maliciously, not in the sense of being weak, but being cooked up to make some message forgeable).

It's rather redundant when R is hashed, when the curve is rigid, when the curve is pseudorandom (e.g. brainpool), and perhaps even if the curve is not CM. ‎Nonetheless, it seems to provide protection independent of those others, and it seems cheap.

It's fair to ask if it some other security risk.

  Original Message
From: Ilari Liusvaara
Sent: Friday, August 7, 2015 9:10 AM
To: [email-masked]
Subject: [Cfrg] Signatures: curves/hashes by key vs. by invocation

-Ilari

_______________________________________________
Cfrg mailing list
[email-masked]
https://mail.ietf.org/mailman/listinfo/cfrg