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

[Ilari Liusvaara <[e-mail]>]

On Thu, May 21, 2015 at 07:17:48PM -0700, Tony Arcieri wrote:
> 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?

Yeah, collisions in first hash cause signature collisions.
 
> 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.

Add input for hash domain (with special value for "identity"):
- This is not hashed.
- This is SHA-256 output
- This is SHA-384 output
- This is SHA-512 output
- This is Blake2b-512 output
...
?

That also prevents mismatching hashes between signer and verifier.

Also, I thought that was #3 (can choose between online and offline)?

> #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)

The only signature in TLS (including TLS 1.3 as of editor's copy) that is
actually over nontrival amount of data is TLS 1.0-1.2 Client certificate
verify.

And if the PRF-hash in TLS is not CR, one gets problems...


-Ilari