Re: [Cfrg] Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

[Tony Arcieri <[e-mail]>]

On Thu, May 21, 2015 at 3:49 PM, Watson Ladd <[e-mail]> wrote:

> On the contrary, 3 would hurt unless properly designed. The danger is
> that the same key could produce a valid signature under two different
> algorithms, thus leading to potential exploitation.


Something that strikes me as a bit strange is if we do hash the input prior
to feeding it into #2, doesn't that defeat the point? Collisions in the
first hash are still collisions. So wouldn't any collision in the hash
function undo any collision-resistance that #2 provides? Am I missing
something here?

How about option #5(?): provide both #1 + #2. Implementation-wise you could
share the overwhelming majority of the code between both interfaces. The
difference between them seems trivial enough that providing both should be
easy. And to Watson's point, if we do it that way there shouldn't be any
chance of confusing the two as they should produce completely distinct
signatures.

#2 seems very nice for the TLS use case, especially as we've seen
collisions in older hash functions being used in real-world attacks against
TLS (e.g. Flame). I'm not saying I expect to see collisions in SHA-256 any
time soon, but I would hate to see #2 rendered unavailable because we can't
otherwise meet the requirements of low-memory devices signing large amounts
of data (FWIW, I think in most real-world use cases in those environments
the data is always going to be hashed in advance, probably by another
computer which actually has the memory to compute the hash)

-- 
Tony Arcieri