Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise

[Rene Struik <[e-mail]>]

Dear colleagues:

It is by now obvious that the current deterministic signature schemes EdDSA (RFC 8032) and
det-ECDSA (RFC 6979) can be trivially attacked in practice. So, clearly something must be done
about this.

I would suggest another approach than John Mattson's, though, which is more fundamental and
avoids hard-coding a specific mandated way of generating ephemeral private key altogether (after
all, random number generators can be implemented in more than one way).

I do not think labeling the fix as only "RECOMMENDED" is sufficient: the original schemes are
fundamentally flawed for wide-scale adoption and the fix should be surrounded by stronger "MUST"
language.

On a non-technical note, I am curious how RFC 8032 came to be, even though the fault attacks were
well-known prior to issuing the standard. I have not checked all email threads at the time, but
remember that, e.g., Manfred Lochter from BSI has repeatedly made this point inside and outside
the CFRG.

More details on suggested alternative approach below.

==

My understanding of the issues:

a) deterministic EdDSA and ECDSA impose side-channel and fault attack risk, due to way
ephemeral private keys are generated;
b) {from comments John Mattson to draft FIPS 186-5 (these comments have now finally
been posted, I saw this week)}: EdDSA with SHA-256 would be good with IoT applications

CFRG proposal John Mattson addresses an aspect of a), but not b).

Would one be open to a slightly enlarged proposal towards addressing a), but that also makes
it easier to realize b)?

In my mind, we could do the following:

1) define Schnorr signature generation and verification more generally, with random
generation ephemeral private keys;
2) specify instantiation with Ed25519/SHA512/LSB-lsb encoding and Edwards448/SHAKE/LSB-lsb
encoding, which would be fully compatible for verifiers with RFC 8032;
-- this includes informative section on how to generate ephemeral private key k as
k:=H(d0,rnd,m) (mod n).

Result:
i) This would allow cleaning up RFC 8032 (as John's draft does), but with following differences:
-- generation of ephemeral private keys k could also be in different way (e.g., for HW vendors
that already have good RNG on board), so as to allow only one pass of message to be signed,
rather than two with current Pure EdDSA specification.
-- more separation of specification and implementation details, so that RFC does not have to
be rewritten once more implementation vulnerabilities are discovered (since
not impacting specification).
ii) This would easily allow specification of EdDSA, but now randomized and with SHA256 instead
of SHA512 {addressing your point b)}.

Tangential effects:
iii) This would making all kinds of other CFRG drafts easy to describe (e.g., vrf drafts);
iv) This would allow Schnorr to be used with P-256 and SHA-256 as well;
v) This would help in describing Opaque password proposal, which (if one uses HMQV) requires a
Schnorr scheme under the hood (HMQV is, loosely speaking, based on Schnorr).

One of the side benefits of this is that we stop the recent practice of CFRG to produce drafts
that are a curious mix of specification and implementation details (which makes all of this
academic paper generator in the SCA-space).

Best regards, Rene

On 4/28/2020 7:23 AM, Stanislav V. Smyshlyaev wrote:
> Dear CFRG participants,
> This email commences a 2-week call for adoption for 
> draft-mattsson-cfrg-det-sigs-with-noise-02 that will end on May 12th 2020:
>
> https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/
>
> Please give your views on whether this document should be adopted as a 
> CFRG draft, and if so, whether you'd be willing to help work on 
> it/review it. Please reply to this email (or in exceptional 
> circumstances you can email CFRG chairs directly at 
> [e-mail] <mailto:[e-mail]>).
>
> Thank you,
> Stanislav (for the chairs)
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]