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

[Hannes Tschofenig <[e-mail]>]

I have asked my co-workers to review the draft and Janos Follath responded. He thinks that this idea to add randomness makes perfect sense.

Here is his response on the discussion points listed in the draft:

  *   One of the goals of the document is to provide the same security level against side channel attacks as a randomised scheme. Using 16 bytes of randomness with Ed25519 fails to achieve this: Ed25519 has 128 bit security, using 128 bits of random data results in collisions after 2^64 signatures (the attack we are defending against already assumes that the attacker can trick the device into signing the same message repeatedly) and every collision reduces the noise in the attacker’s measurements. The overhead is minimal, this is a standard that should recommend good practices, I don’t think this is the right place trying to gain performance improvements.
  *   This question seems to be rather off-topic for this RFC. Nevertheless my thoughts: Whether we use HMAC or KMAC, the schemes are secure, the difference is a minor performance gain. Both variants generate valid signatures, the verifier does not need to know which was used to generate the signature, thus there is no compatibility issue between the two variants. Including both in the IETF standard would allow implementors to choose between NIST compliance and a slight performance gain. (Of course if NIST can be convinced to approve a KMAC-DRBG in SP 800-90-A or diverge from that construction in FIPS 186-5, then everybody can just use KMAC.) That being said, if I had to decide, I would stick with HMAC: the performance gain of KMAC is minimal and SHA2 is still around, I wouldn’t want to risk implementors accidentally trying to use SHA2 with KMAC under any circumstances.

Here are my personal thoughts on this entire topic:


Classical ECDSA required a random value for signature creation.

Then, RFC 6979 was written because there was a concern about environments that do not have access to a source of high-quality randomness. This concern has often been stated in context of Internet of Things devices. You can read about these concerns even in recent IETF documents, such as https://tools.ietf.org/html/draft-ietf-ace-coap-est-18. In that document the authors added a technique to have server-generated keys that are then sent to IoT devices to deal with the lack of a good source of high-quality randomness.



Now, with draft-mattsson-cfrg-det-sigs-with-noise we are adding randomness back into RFC 6979.



Are we now back to where we started?

Ciao
Hannes


From: Cfrg <[e-mail]> On Behalf Of Eric Rescorla
Sent: Wednesday, May 13, 2020 1:49 AM
To: Stanislav V. Smyshlyaev <[e-mail]>
Cc: CFRG <[e-mail]>; [e-mail]
Subject: Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise

I didn't study the algorithms in detail, but this seems generally sensible and worth adopting. I agree with others that we probably should change the title to avoid confusion.

-Ekr


On Tue, Apr 28, 2020 at 4:23 AM Stanislav V. Smyshlyaev <[e-mail]<mailto:[e-mail]>> 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]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.