Re: [Cfrg] Elliptic Curves - signature scheme: randomised or not (ends on May 13th)

[Andrey Jivsov <[e-mail]>]

On 05/11/2015 01:26 PM, Nico Williams wrote:
> On Mon, May 11, 2015 at 08:02:13PM -0000, D. J. Bernstein wrote:
>> Nico Williams writes:
>>> replacing M with H(M) in the second hash
>> This makes the signature scheme vulnerable to collisions in H. This
>> _shouldn't_ be a problem, since the community puts a lot of effort into
>> designing hash functions for which finding collisions seems to be
>> extremely difficult; but it's safer to build collision-resilient
>> signature systems, using collisions as an early-warning mechanism.
> Right.  Fot the record, I'd prefer to not replace M with H(M) in the
> derivation of k.  Instead I'd rather not have hardware like Andrey
> posited.

This is a somewhat separate question about the hashing twice 
(https://www.ietf.org/proceedings/92/minutes/minutes-92-cfrg search for 
"twice"), but I view that the related concerns supports the idea of a 
random k esp. with protocols that deal with messages of unlimited size.

Nico: you are against the interpretation of EdDSA as done in 
https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00#section-5. 
If you are against, consider what the code like "cat InFile | gpg 
--clearsign" suppose to do then? (I assume that this piping is what 
influenced this particular interpretation of EdDSA.)

Because pipes are unidirectional, M (v.s. H(H)) protocol forces the code 
to buffer the message into a temporary file. Creating a temporary file 
amplifies the concern in 
http://www.ietf.org/mail-archive/web/cfrg/current/msg06759.html (e.g. 
consider some setup with different privileges): there is a good chance 
that an implementation will do the second hashing on the temp file, but 
not the first (because the first hashing can be performed on the piped 
in content).

>
> It is clear that some users have a use for randomized k's, and that will
> interop with a deterministic, stateless signature scheme that derives k
> from the secret key and the message.  There's no way to prevent that,
> so/and we shouldn't try, but the signature scheme that CFRG settles on
> should be deterministic and stateless as specified.

I generally agree with this. Just don't criminalize / recognize the 
benefit of random 'k' (with the security caveats).

> Nico