Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

John Mattsson <john.mattsson@ericsson.com> Tue, 10 March 2020 05:45 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67BE3A0442 for <cfrg@ietfa.amsl.com>; Mon, 9 Mar 2020 22:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmhMxzGZy4lK for <cfrg@ietfa.amsl.com>; Mon, 9 Mar 2020 22:45:06 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A403A045E for <cfrg@irtf.org>; Mon, 9 Mar 2020 22:45:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DHnsknxoHpvHmBPFbUUWVR5tfDB/r7Do0hW4E+RVZByplw6j1UaeCgx2DXUaZm?= =?utf-8?q?+aUf1t+/wwzolhrPxLVS+pFKXqxmBJZpj2Oqas9tdMmXyERJQEci9tBLGlCXDTRXJ?= =?utf-8?q?ZwlkKhSXlFjjjLmrgFS1b6zD725JtoNaf/mgJHewwcpS1fW6K7bz5HXDZpwvtOkne?= =?utf-8?q?6Ofny0vqOyxfigIlVI/Nkp1OK/YeZVMwOQ2pp95XnV3kNCT8TIHqg49azEGeOazvI?= =?utf-8?q?b7p0mJa3f+ORi6xg7i1bjg8BHhux4EbZb7ypf4n6u1XVfr7rUr1kNyD82sJkYU+XX?= =?utf-8?q?uaXZpemG8ue2Lydzp/XbA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DejE7y2mmlOex0FMyb4lh6RovxVV7oo7/g6S3KjDxI7U=3D=3B_b=3DY0hwWL?= =?utf-8?q?USBWEKgONRYaT+Xdqp3TlYUn/6ubPU9K6AL48MTmwuO1b8CC4IRoctmYL7nzxCXA2?= =?utf-8?q?Ly9osmrxyI1yQ21KY6bsj+M1nv9d9kFq8KdV1CIez3O2T5OnVhosoJB7zseQL4jGa?= =?utf-8?q?2fCcOuIFQmcjisYTZepDKatrFuHNknMCT+eNu48xkPFNQ0J0E6P9k33IaAndLsNKs?= =?utf-8?q?uHGrYL1RAydzNB3DcZlu1EJeOnyJeOZz5GDNLa7tC7Y4phzhzCtjH4WN4nizlxC4R?= =?utf-8?q?rJuc41orJw8AV41QKlv3JzhoH4autlMpX858M70m37KDDvWj1X4XZ/2QfH/vc/y9v?= =?utf-8?q?bAQ2KlmttSQ=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DejE7y2mmlOex0FMyb4lh6RovxVV7oo7/g6S3KjDxI7U=3D=3B_b=3DPPwa+h?= =?utf-8?q?i48De0b4yoDbqJ4TaX6qtUXOSkS1EatfQw9lhdn7kAyE9ry1mJkxhsMGZH4+WkcLq?= =?utf-8?q?IrR0UR9+vLoFFp2C6zF/w81srclIipzQxksVHDR3Rm3CThgDf/5kH/Jxfs6hwcj9h?= =?utf-8?q?cvd0JQPc9FKSsnvvwxhxlYyRVYt83yolXxY=3D?=
Received: from AM6PR07MB4134.eurprd07.prod.outlook.com (52.134.114.155) by AM6PR07MB5009.eurprd07.prod.outlook.com (20.177.189.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.10; Tue, 10 Mar 2020 05:44:58 +0000
Received: from AM6PR07MB4134.eurprd07.prod.outlook.com ([fe80::501f:822f:f9b5:eb71]) by AM6PR07MB4134.eurprd07.prod.outlook.com ([fe80::501f:822f:f9b5:eb71%7]) with mapi id 15.20.2814.007; Tue, 10 Mar 2020 05:44:58 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>, Tony Arcieri <bascule@gmail.com>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt
Thread-Index: AQHVtO9lOZJrcNc7J0+AzBoiSFtzNKe+m+GA///5fgCAeRb1ZIAJr5qA///xkICAAJd2gA==
Date: Tue, 10 Mar 2020 05:44:58 +0000
Message-ID: <1DA3C97B-6FF3-4338-8CEF-D5D743AF6F0E@ericsson.com>
References: <157659682819.26470.8755515351900237330.idtracker@ietfa.amsl.com> <E6D46D5C-2BDA-466D-A2BF-46FC39605B8E@ericsson.com> <CAHOTMVJbpSUureq6V4pdZbHS2otF6CkchFYdTvCjB_CxxANijA@mail.gmail.com> =?utf-8?q?=3CCH2PR09MB422045123171EBCAD949FDFEF3E40=40CH2PR09MB4220=2Enampr?= =?utf-8?q?d09=2Eprod=2Eoutlook=2Ecom=3E?= <D401E76A-1613-4602-8BF4-4329901203D2@ericsson.com> <69D111EF-EF28-4A4C-A3C8-AF9676821299@ll.mit.edu>
In-Reply-To: <69D111EF-EF28-4A4C-A3C8-AF9676821299@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [82.214.46.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd003a0f-5a7e-429f-c996-08d7c4b62b1d
x-ms-traffictypediagnostic: AM6PR07MB5009:
x-microsoft-antispam-prvs: =?utf-8?q?=3CAM6PR07MB5009E3748A60E133B1B5E79B89F?= =?utf-8?q?F0=40AM6PR07MB5009=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:311;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDEzNjAwMykoMzk2MDAzKSgzNzYwMDIpKDM0NjAwMikoMzk4?= =?utf-8?b?NjA0MDAwMDIpKDE5OTAwNCkoMTg5MDAzKSg2NjQ0NjAwOCkoMjkwNjAwMiko?= =?utf-8?q?44832011=29=286486002=29=286512007=29=288936002=29=2871200400001?= =?utf-8?b?KSg1MzU0NjAxMSkoNTY2MDMwMDAwMikoNjUwNjAwNykoNDc4NjAwMDAxKSg5?= =?utf-8?q?66005=29=2864756008=29=2876116006=29=2866476007=29=284326008=29?= =?utf-8?q?=2866946007=29=288676002=29=2891956017=29=2866556008=29=286661600?= =?utf-8?q?9=29=2833656002=29=2881156014=29=2886362001=29=2815650500001=29?= =?utf-8?q?=2881166006=29=284001150100001=29=28186003=29=28316002=29=2811013?= =?utf-8?b?NjAwNSkoNjY1NzQwMTIpKDM2NzU2MDAzKSgyNjAwNSkoMjYxNjAwNSk7?= DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5009; H:AM6PR07MB4134.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?zFJiV/CbN1xYWtq1atXWos4GVC2ArkS?= =?utf-8?q?fmcVjCnPrMB1vZxz7Xf0B9snIQHCFIKHfYzNNOQ2hFk1ZCiS4OHEI8I4YRjwlt+iw?= =?utf-8?q?55sn4Omfz4godBfBzZ3SnhvpWD5cnjTo5qqlb1tuyOgFyfauH2nP2k4G4hrAiNfD2?= =?utf-8?q?jfm+LIaIG27r8AhZIIOxx7k28XbrL94JYtuDaK4vHzJE5cLmdZsNmMQwVfxvAP9cI?= =?utf-8?q?wuu+CBzofhRPffOtcqU8GZQGJKtvben7kXnUGVfGPIBoTPdwLQU80dqX4+iXtKCIo?= =?utf-8?q?fC1V03DrtnZH3IrHOrDQXuAap4vYgW2xFJZtxRfe5rOjCO/mXeRXaEKk5Oi81wPP3?= =?utf-8?q?HS6leGK2ozUQCsbJ7INKG3sNZ1Kgxpcy4Yu4YjOcbBoTPF50V2ezSKWPxF59BQzzf?= =?utf-8?q?tXu6EIYXb526i87nDZ9e5H0t99vAeftKelxcAYLT5rbrYHYLiJJZRrHtQYCDAah32?= =?utf-8?q?UM1tvV0TJARohY6OenjQiSSsTfEXpn/L5mz9ZqWnoW6bkq1A=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?zwkrURpXJEL3Y4BNUyh6JBmnHZgmhZ?= =?utf-8?q?A9Sq+gFawv9AYfJzXgMqAiQ78EO6fJKTfT2d6/oGkAePQjeDP8wqW6XOF1MGtCwTl?= =?utf-8?q?5YUPcoEIEWICXrTGGp0o0/Ro8pICGwdv+V3tZzsLqCwLwg1rzOi6pyQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3666667497_1607984180"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd003a0f-5a7e-429f-c996-08d7c4b62b1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 05:44:58.2069 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?FBgBVuHVoE0kAecxEGEaS?= =?utf-8?q?R4jSp5euWRhOnBPRT9vp5v3D+/ZW/3dauzjcRIZDGek+Hl1SuPLTE0UiZCRqXr8X/?= =?utf-8?q?nVQuRnip7vhJm+6MTslik=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5009
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jQmr3IrdhlihRfuDtkt7whBzS7w>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 05:45:11 -0000

Thanks Uri,

 

I’ll change the constructions in the next version to:

 

dom2(F, C) || Z || prefix || 000... || PH(M)

V || 0x00 || Z || int2octets(x) ||  000... || bits2octets(h1)

 

where

 

Z is chosen to be the same length as prefix / int2octets(x)

 

and

 

the number of zeroes 000... is chosen so that the length of 

 

dom2(F, C) || Z || prefix || 000...

V || 0x00 || Z || int2octets(x) ||  000...

 

is equal to the block length of the hash function.

 

Other choices for the length of Z would also be possible, like a fixed length of 32 or 64 bytes.

 

Cheers,

John

 

From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Date: Monday, 9 March 2020 at 22:43
To: John Mattsson <john.mattsson@ericsson.com>om>, "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>ov>, Tony Arcieri <bascule@gmail.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

 

I too prefer

 

( Z || prefix || 000... || PH(M) )

 

over

 

( (prefix XOR Z) || PH(M) ) 

 

Yes there is a reason for those zeroes.

 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Date: Monday, March 9, 2020 at 5:37 PM
To: "Dang, Quynh H. (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>rg>, Tony Arcieri <bascule@gmail.com>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

 

Thanks for the review Quynh!

 

I agree that there are compelling reasons to do as you suggests. We never considered

 

( Z || prefix || PH(M) ).

 

We chose

 

( (prefix XOR Z) || PH(M) ) over the XEdDSA construction ( prefix || PH(M) || Z )

 

as https://eprint.iacr.org/2017/985.pdf states the the XEdDSA construction did not protect against all of their attacks due to insufficient mixing of the hashed private key with the additional randomness. Do you see any need to insert zeroes like

 

( Z || prefix || 000... || PH(M) )

 

as suggested by https://eprint.iacr.org/2017/985.pdf so that the first 1024-bit block of SHA-512 is composed only of the hashed private key and the random value, but not the message?

 

I agree with you that the cost of hashing operations are not really worth optimizing as their cost is negligible compared to the cost of the Elliptic curve point multiplications. We have not looked into how much additional security the zeroes gives in practice.

 

PS. We would also be very happy if NIST just went ahead and standardized some variant of  deterministic signatures with additional randomness in FIPS 186-5 :)

 

Cheers,

John

 

From: "Dang, Quynh H. (Fed)" <quynh.dang=40nist.gov@dmarc.ietf.org>
Date: Tuesday, 3 March 2020 at 20:36
To: Tony Arcieri <bascule@gmail.com>om>, John Mattsson <john.mattsson@ericsson.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

 

Hi John,

 

I think there are people who would like some noisy deterministic ECDSA/EdDSA options. 

 

I would prefer (Z ||int2octets(x) ) over (int2octets(x) XOR Z) , and   (Z || prefix) over (prefix XOR Z)  for the following reasons.

 

1) For randomized hashing, the random value should get hashed first before the message for a SHA2 hash function ( even thought it is not the same thing here since a secret value is a part of the message).

 

2) Z1 and Z2 both are Z bits long and have Z bits of entropy.  (Z1 Xor Z2) have only Z bits of entropy, but Z1||Z2 have 2Z bits of entropy (if Z1 and Z2 are generated from 2 different seeds/entropy sources). 

 

An extra Z bits long would cost at most 1 compression function for SHA-512 and it would likely not cost anything for SHAKE256.  So, the cost is minimal. 

 

Regards,

Quynh. 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Tony Arcieri <bascule@gmail.com>
Sent: Tuesday, December 17, 2019 12:30 PM
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: cfrg@irtf.org <cfrg@irtf.org>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt 

 

This looks like a good document (so far you've managed to cover every nit I had to pick with it), however I think it might be a bad idea to describe your construction as "with Noise", in order to prevent confusion with the Noise Protocol, which among other things supports an Ed25519 signatures extension (which can, if one so desires, be used with XEdDSA): 





https://noiseprotocol.org/



 

Perhaps "with Added/Additional Entropy" instead?

 

On Tue, Dec 17, 2019 at 8:53 AM John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:

Hi,

I read up a lot more on recent research on side-channel and fault injection attacks on deterministic ECC signatures. This has increased my understanding that deterministic ECC signatures should not be recommended in environments where side-channel and fault injection attacks are a concern. One such environment is IoT deployments where the adversary can be assumed to have access to devices to induce faults and measure side-channels.

As many such embedded devices also lacks a good RNG, none of the currently standardized fully-randomized or fully-deterministic ECC signature algorithms seems like a good choice. I therefore think there is a need to specify deterministic ECC signatures with noise.

My colleagues and I started to write a draft specifying how a random noise can be added to the otherwise deterministic calculation of the per-message secret number. We ended up not proposing the solution chosen in XEdDSA as at least one research paper claims that XEdDSA does prevent their attack due to insufficient mixing of the hashed private key with the random noise.

The current document aims to give a quite broad overview with many references, suggests one possible construction for deterministic ECDSA and EdDSA, and lists several issues and TODOs. It should be discussed what the best construction is for achieving protection against fault and side-channel attacks, simplicity and ease of implementation, as well as efficiency. Comments are very welcome!

Cheers,
John

-----Original Message-----
From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Date: Tuesday, 17 December 2019 at 16:33
To: John Mattsson <john.mattsson@ericsson.com>om>, John Mattsson <john.mattsson@ericsson.com>om>, Sini Ruohomaa <sini.ruohomaa@ericsson.com>om>, Erik Thormarker <erik.thormarker@ericsson.com>
Subject: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt


    A new version of I-D, draft-mattsson-cfrg-det-sigs-with-noise-00.txt
    has been successfully submitted by John Preuß Mattsson and posted to the
    IETF repository.

    Name:               draft-mattsson-cfrg-det-sigs-with-noise
    Revision:   00
    Title:              Deterministic ECDSA and EdDSA Signatures with Noise
    Document date:      2019-12-17
    Group:              Individual Submission
    Pages:              14
    URL:            https://www.ietf.org/internet-drafts/draft-mattsson-cfrg-det-sigs-with-noise-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/
    Htmlized:       https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-cfrg-det-sigs-with-noise


    Abstract:
       Deterministic elliptic-curve signatures such as deterministic ECDSA
       and EdDSA have gained popularity over randomized ECDSA as their
       security do not depend on a source of high-quality randomness.
       Recent research has however found that implementations of these
       signature algorithms may be vulnerable to certain side-channel and
       fault injection attacks due to their determinism...  One countermeasure
       to such attacks is to add noise to the otherwise deterministic
       calculation of the per-message secret number.  This document updates
       RFC 6979 and RFC 8032 to recommend constructions with noise for
       deployments where side-channel attacks and fault injection attacks
       are a concern.




    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


 

-- 

Tony Arcieri