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

Dan Brown <danibrown@blackberry.com> Wed, 06 May 2020 17:49 UTC

Return-Path: <danibrown@blackberry.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 64A1B3A0948; Wed, 6 May 2020 10:49:44 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=blackberry.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 gg2EBT_F2gxf; Wed, 6 May 2020 10:49:41 -0700 (PDT)
Received: from smtp-pc10.blackberry.com (smtp-pc10.blackberry.com [74.82.81.42]) (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 22B973A00D2; Wed, 6 May 2020 10:49:39 -0700 (PDT)
Received: from pps.filterd (mhs400cnc.rim.net [127.0.0.1]) by mhs400cnc.rim.net (8.16.0.27/8.16.0.27) with SMTP id 046Hl8oW054559; Wed, 6 May 2020 13:49:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=HXZY50Gr/U+EU7TZ7LTuo4CJgHjhckZ8nExyYh/BAIw=; b=mbj9ewJUjoT0XqtmVGAaDqmWTnnrcOk/IYWwbZ0O5uXV+DJhKCF9X1zN3YBacrxIlY8L /TKSxuRwUGAc28L+oqlXkvzFcnfnNzYv3Yu2kwtD6KZ+doRoST+n8nYRMqigiYmHpv03 uWADj5dkL2A+tJ0DD5Y9LbNxrOD36nmsTnlxdjFKy6rrHrHsBF8MFM64y2ZQzGXdC6k3 KRahckcA8yu9JwhN39E0RH8D/19+18bqJWvveZK8/5AoEn0Ft5OOam6mrsyAoyqUjGhS SdRc4CptssyQUV+oXoj89QT5jryrODMe6NKd7JvO8bQTtnskIOU1ExbujMD7/rfqZZ/6 rw==
Received: from xch210ykf.rim.net (xch210ykf.rim.net [10.2.27.110]) by mhs400cnc.rim.net with ESMTP id 30uk6y1gb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 06 May 2020 13:49:36 -0400
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH210YKF.rim.net (10.2.27.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 6 May 2020 13:49:35 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Wed, 6 May 2020 13:49:35 -0400
From: Dan Brown <danibrown@blackberry.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, CFRG <cfrg@irtf.org>
CC: "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>
Thread-Topic: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise
Thread-Index: AQHWHU98BCvrFkxt+EyG8s4VhUz4OKibQBmA
Date: Wed, 06 May 2020 17:49:35 +0000
Message-ID: <e751f285bc814825b42d39d97a0d84aa@blackberry.com>
References: <CAMr0u6kr18AP2ya5Pn2VXpt6FLO6vWrFQoXrFni28uYgrJXpFA@mail.gmail.com>
In-Reply-To: <CAMr0u6kr18AP2ya5Pn2VXpt6FLO6vWrFQoXrFni28uYgrJXpFA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.39]
Content-Type: multipart/signed; micalg="2.16.840.1.101.3.4.2.1"; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0011_01D623AD.2BB3B400"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-06_09:2020-05-05, 2020-05-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/RMKRGfcXuE6S2BIjcrZkJDAvZiE>
Subject: Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise
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: Wed, 06 May 2020 17:49:45 -0000

It seems fine to adopt this, but a few things should be checked.

 

 

Procedurally, randomizing signatures is a *reversal* of CFRG consensus towards determinism, so maybe past discussions on CFRG are worth reviewing (I have forgotten the arguments). Maybe determinism proponents are too busy to check here, and should be briefly queried.

 

https://mailarchive.ietf.org/arch/msg/cfrg/NKiP_VOxTNI6lhukz7BP1Dh5kkk/

https://mailarchive.ietf.org/arch/msg/cfrg/QI6-EXVWtcAwBc6WakKl5YmZZlA/

https://mailarchive.ietf.org/arch/msg/cfrg/76HvHx_wXgIZJDr2COO8xQM8tZA/

 

 

How much side-channel resistance is gained from randomization? A mild gain sounds plausible to me, but I would to defer to side channel experts, e.g., if they think they think it a loss.  Perhaps determinism + side channel exposes the same bits over and over again (e.g. if the signed message is the constant), but randomization + side channel exposes new bits (for a constant message), making randomized more vulnerable?

 

 

I wonder if some applications of signatures now rely on non-standard, off-label properties of signatures, e.g. determinism (or non-determinism for older applications).  (Non-standard here means something 

different from Goldwasser-Micali-Rivest unforgeability against adaptive chosen message attacks.)  For example, maybe EdDSA is somewhere being used like a verifiable hash?  (Ok, any verifier reliance on determinism is probably insecure, because the signer switch over to non-determinism.)

 

​​​​​

Should we continue to name these “deterministic” signatures, if the plan is to make them non-deterministic?  

 

How about message-dependent signatures, since both components of the signature (R,S) will depend on the message? Or message-keyed, to emphase that R must depend on M, not just S.  (Multi-word phrases have precedents, I am reminded of nonce-misuse resistance, thought does not fit here.)

 

I am partly repeating here my past suggestions to CFRG, where I argued that it would be “deterministic” (but insecure!) to always re-use the same ephemeral key (aka nonce, per-message secret).  Hence “deterministic signature” is like naming an armored car, a “heavy car”. 

 

Dan

 

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Stanislav V. Smyshlyaev
Sent: Tuesday, April 28, 2020 7:23 AM
To: CFRG <cfrg@irtf.org>
Cc: cfrg-chairs@ietf.org
Subject: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise

 

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/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmattsson-2Dcfrg-2Ddet-2Dsigs-2Dwith-2Dnoise_&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=ydtZz5PC4Sux3jOiCX58oVZerBsDmsFrMLrXoTd40sc&s=2Hv35e8ePak-1MtzQnsFFQG5R1VOOCG1zZHav675APw&e=>   

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 cfrg-chairs@ietf.org <mailto:cfrg-chairs@ietf.org> ).

Thank you,
Stanislav (for the chairs)

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.