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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 07 May 2020 17:29 UTC

Return-Path: <prvs=239673a099=uri@ll.mit.edu>
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 62F223A00D9 for <cfrg@ietfa.amsl.com>; Thu, 7 May 2020 10:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NgImnisD9MKd for <cfrg@ietfa.amsl.com>; Thu, 7 May 2020 10:29:52 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 1ADAB3A0CB8 for <cfrg@irtf.org>; Thu, 7 May 2020 10:29:46 -0700 (PDT)
Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 047HTeNH030481; Thu, 7 May 2020 13:29:40 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Natanael <natanael.l@gmail.com>, Dan Brown <danibrown@blackberry.com>
CC: CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise
Thread-Index: AQHWHU+JkZmddLsth0SsTBBrhhDTlqibpdeAgAEOjgCAADsmAA==
Date: Thu, 7 May 2020 17:29:39 +0000
Message-ID: <734983EF-23AB-4919-9A2B-D0D3A92F9812@ll.mit.edu>
References: <CAMr0u6kr18AP2ya5Pn2VXpt6FLO6vWrFQoXrFni28uYgrJXpFA@mail.gmail.com> <e751f285bc814825b42d39d97a0d84aa@blackberry.com> <CAAt2M1_w+0BsP6M_Kw-PZ5atOCb96ut7b5nL_kfe7mgGsyr6LQ@mail.gmail.com>
In-Reply-To: <CAAt2M1_w+0BsP6M_Kw-PZ5atOCb96ut7b5nL_kfe7mgGsyr6LQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-originating-ip: [172.25.1.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3671702978_926081686"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-07_10:2020-05-07, 2020-05-07 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005070142
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/D1pnSW9YIFvLzOcXbQJeraCRXPU>
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: Thu, 07 May 2020 17:29:55 -0000

The way I see it (and I confess that I didn’t dive into this at all ;):

 
Security of randomized signatures depends on availability of a good RNG on the platform.
To mitigate the absence of a good reliable RNG, people defined deterministic signatures. 
Deterministic signatures appear vulnerable to side-channel attacks.
To mitigate these side-channel risks without re-introducing the need for a good RNG, “some” randomness is added.
 

So, to the Dan’s point – it’s  not a “reversal”, because it doesn’t expect a great RNG to be present. It merely hopes to get “some” randomness sufficient to mitigate side-channel attacks. While the “mostly” deterministic algorithm foils cryptographic attacks that exploit poor randomness.

 

Did I get it right? ;-)

 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Natanael <natanael.l@gmail.com>
Date: Thursday, May 7, 2020 at 05:59
To: Dan Brown <danibrown@blackberry.com>
Cc: CFRG <cfrg@irtf.org>rg>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>
Subject: Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise

 

 

Den ons 6 maj 2020 19:49Dan Brown <danibrown@blackberry.com> skrev:

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. 

>From my reading & in my layman's opinion, the primary goal of deterministic designs is to reduce the risk of bad entropy sources breaking the system. So it wouldn't be too much of a change of course when the goal is to increase robustness of the use of entropy, IMHO. But acknowledging the change makes sense. 

 

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

 

There's a separate class of functions called VRF (verifiable random functions) that should be used if what you need specifically is something that is equivalent to reliably deterministic signatures. 

 

I've seen cryptocurrency projects rely on assumptions of deterministic signatures and getting attacked because of it, but these designs were flawed from the start and probably shouldn't be catered to. People making assumptions like this needs to verify if the algorithm / implementation actually provides those properties before using them. It would be much better in cases like this to explicitly explain which properties are provided and which aren't, so that flawed choices like this aren't made by implementors in the first place. 

 

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'm reminded of the term "ciphertext stealing" from the XTS cipher mode. The signature (it parts of it) always was message dependent, but maybe "entropy stealing" or similar phrasing could be used since we take secret randomness from additional sources to make the signature algorithm more robust. 

 

Maybe a more neutral term like "entropy combining" would work better. "Entropy combining signatures".