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

Rene Struik <> Wed, 13 May 2020 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DAC53A0B36 for <>; Wed, 13 May 2020 06:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x-rzx2DgdjHi for <>; Wed, 13 May 2020 06:23:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DFC63A08D1 for <>; Wed, 13 May 2020 06:23:14 -0700 (PDT)
Received: by with SMTP id z80so11712577qka.0 for <>; Wed, 13 May 2020 06:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=fkUHMCrXqH571lGLj49hSe+VyAX0WuFcqM+uIab6ueY=; b=Wdu/iLpJso8cwnpJ2N0Ly8vJNC66RVLj6LL8VR/3CEx3/OTPbr97QXqV5XVAGlVjAy EqRNVb2HMQo7CwpRfgstG+e5m94ItOKMFHW7wkWMhdxUAbdln1VovRM87+K0tmxPnHAm KDDWVSg8kIqeMekqaFGFFEms9jMYy7N8zI1jQWAND0+ACzJwF3O/ndQWozd7G+mE6GMn 0JxdY7OAk2PFlSnEGhmJsaK1tuNErKE/gU/wRf3TuxcpTSpPdyxhjCmj7P86c/RKHYBL onTOfGFIo3z9vTX82GINDO+bC39v/9b2hUjeg9YBi7BeUi/Ebt0kv9dn9SDJml2xlJQ4 FhCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=fkUHMCrXqH571lGLj49hSe+VyAX0WuFcqM+uIab6ueY=; b=GbKYR41MhbCLCUDpwuQd/f1cVww11PdO9o95bCEZIfOHppri7RwR7vMSoshi02aATL ezyQEC7EkVUy1JkqyuIwXdIP+TVO5Aw+F2A8aIyjdkWwUImTF2LR3V5N/XdA6/ZjQ4nx mNORl1Grqnv07sPs9dX3AYed8Y+jhWByH6jAm2HGAzxyTXNRBWKS6ZBFqLEHp0SE/uzQ QxAOhnyrqnR6mdnqq091fEm2pSipyvoUVLNsuuNeGog4lpg/66icpt/3Hbwdf7nriCZW XAklCB2nDrj1URJ17lrPtJPSRM88BuEXaS2cir289h112Oo/r/i32SwCBhTbVK9VGCIj m3Uw==
X-Gm-Message-State: AGi0PuY6pxOQv6ceYteqQwpSwg/VFARQeiXw5G//N73W2+0SC9HnIqgT T2FNRLSO+FXluJthxQRR9C0=
X-Google-Smtp-Source: APiQypKSbYBQIgpQKqkMBoQCUwZh4h3NpLDPvJqr+frIQEJvZH8Iwp+uBOQJH7h8rvmQMgkd06b+bA==
X-Received: by 2002:a05:620a:490:: with SMTP id 16mr25409225qkr.203.1589376193130; Wed, 13 May 2020 06:23:13 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:9833:861e:62ac:a462? ([2607:fea8:8a0:1397:9833:861e:62ac:a462]) by with ESMTPSA id b129sm12048842qkc.58.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 06:23:12 -0700 (PDT)
To: "Stanislav V. Smyshlyaev" <>, CFRG <>
References: <>
From: Rene Struik <>
Message-ID: <>
Date: Wed, 13 May 2020 09:23:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------71F6C3A7A286B2F2D8F94184"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2020 13:23:17 -0000

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"

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

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:
> 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 
> <>).
> Thank you,
> Stanislav (for the chairs)
> _______________________________________________
> Cfrg mailing list

email: | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867