Re: [Cfrg] [saag] Recommendations Regarding Deterministic Signatures

Benjamin Kaduk <kaduk@mit.edu> Thu, 28 November 2019 19:38 UTC

Return-Path: <kaduk@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 2AB361208C6; Thu, 28 Nov 2019 11:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 wZbbh99qOG6x; Thu, 28 Nov 2019 11:38:08 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 011BA120823; Thu, 28 Nov 2019 11:38:07 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xASJc2sN017885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Nov 2019 14:38:04 -0500
Date: Thu, 28 Nov 2019 11:38:01 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "saag@ietf.org" <saag@ietf.org>
Message-ID: <20191128193801.GU32847@mit.edu>
References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4QoDJpVRgNJ5KXxNW4A6eFqKBVc>
Subject: Re: [Cfrg] [saag] Recommendations Regarding Deterministic Signatures
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, 28 Nov 2019 19:38:09 -0000

On Wed, Nov 27, 2019 at 11:13:55AM +0000, John Mattsson wrote:
> IRTF/IETF has the last years heavily promoted purely deterministic signatures:
> 
>   RFC 8152 (EdDSA):
>     "EdDSA signatures are deterministic."
> 
>   RFC 8152 and RFC8152bis (COSE): 
>     "Implementations SHOULD use a deterministic version of ECDSA"
> 
>     "Note: Use of a deterministic signature technique is a good idea
>      even when good random number generation exists."
> 
>   RFC 8446 (TLS 1.3)
>     "It is RECOMMENDED that implementations implement "deterministic ECDSA""
> 
> NIST has just released FIPS 186-5 (Draft) where they plan to include deterministic ECDSA but does not recommend it in general due to side-channel and fault injection attacks:

Can anyone comment on the relative weight that NIST gives to hardware vs.
software-only implementations?  My understanding is that these attacks can
be quite severe for hardware implementations.

> My current view is that best practice seems to be to use deterministic algorithms (deterministic ECDSA or EdDSA) with "additional randomness" / "noise" like in XEdDSA. This also mitigates attacks on theoretical use cases where deterministically signing the same message twice leaks information.
> 

This does seem like an attractive proposition on first inspection.

Thanks,

Ben