Re: [Cfrg] Deterministic signatures, revisit?

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 09 October 2017 17:49 UTC

Return-Path: <ilariliusvaara@welho.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 87C1E134570 for <cfrg@ietfa.amsl.com>; Mon, 9 Oct 2017 10:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Uu2g_trMMf1d for <cfrg@ietfa.amsl.com>; Mon, 9 Oct 2017 10:49:52 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFD71346B0 for <cfrg@irtf.org>; Mon, 9 Oct 2017 10:49:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 464F8B51AF; Mon, 9 Oct 2017 20:49:43 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id VqYl-SKWZTq7; Mon, 9 Oct 2017 20:49:43 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 88F0827F; Mon, 9 Oct 2017 20:49:39 +0300 (EEST)
Date: Mon, 09 Oct 2017 20:49:39 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Tony Arcieri <bascule@gmail.com>
Cc: Dan Brown <danibrown@blackberry.com>, Cfrg <cfrg@irtf.org>
Message-ID: <20171009174939.uaapnl772ynvjpoq@LK-Perkele-VII>
References: <20171009165655.8609877.65333.18037@blackberry.com> <CAHOTMVJBDeVYCuLsLQ-KvCFmMNS2uEmB1Bh7208NGtxMpk3hdA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHOTMVJBDeVYCuLsLQ-KvCFmMNS2uEmB1Bh7208NGtxMpk3hdA@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/TBSNoVYj0MB3KNmE1Isi33hSxZ0>
Subject: Re: [Cfrg] Deterministic signatures, revisit?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Mon, 09 Oct 2017 17:49:54 -0000

On Mon, Oct 09, 2017 at 10:30:19AM -0700, Tony Arcieri wrote:
> This certainly keeps coming up. Beyond those papers see the previous "Side
> channel attack and Edwards curves" thread on this list:
> 
> https://mailarchive.ietf.org/arch/msg/cfrg/V1JXfnf05uE88huYaQVKi7iZ6mY
> 
> I think it's definitely a problem that needs to be addressed. I've seen
> various proposals to do so as well, i.e. synthesizing "r" as a combination
> of a random nonce and the message, so that fault attacks would, at the very
> least, require an RNG failure as opposed to always being possible, due to
> repeated "r" values for the same message. This should retain the extant
> defense against RNG failures in general as we saw with ECDSA "k" values,
> since it would still include hashing the message as part of the calculation.

The latter (2017/985) paper in original message seemingly proposed a
countermeasure of that type. The description of countermeasure was not
completely clear, but I _think_ they proposed adding 768 random bits
between prefix and message in calculation of r.

This change would not break compatiblity (the verifier never sees how
r was generated), and if the random bits are bad, the scheme would not
break catastrophically (can not predict r even if all this entropy was
known).

However, it would expose the scheme to additional kleptographic
attacks. An ability to influence the random numbers used would be
enough to compromise the private key.


-Ilari