Re: [Cfrg] Deterministic signatures, revisit?

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 10 October 2017 10:46 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 CB118134472 for <cfrg@ietfa.amsl.com>; Tue, 10 Oct 2017 03:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tlBVJZSb19Cs for <cfrg@ietfa.amsl.com>; Tue, 10 Oct 2017 03:46:17 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9B9134456 for <cfrg@irtf.org>; Tue, 10 Oct 2017 03:46:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 243225372F; Tue, 10 Oct 2017 13:46:15 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id vOU7DAY09bGt; Tue, 10 Oct 2017 13:46:14 +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-smtp3.welho.com (Postfix) with ESMTPSA id 359982313; Tue, 10 Oct 2017 13:46:12 +0300 (EEST)
Date: Tue, 10 Oct 2017 13:46:11 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: Cfrg <cfrg@irtf.org>
Message-ID: <20171010104611.b3lwlawku5zh5aun@LK-Perkele-VII>
References: <20171009165655.8609877.65333.18037@blackberry.com> <20171010102330.8609877.85759.18061@blackberry.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20171010102330.8609877.85759.18061@blackberry.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/76HvHx_wXgIZJDr2COO8xQM8tZA>
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: Tue, 10 Oct 2017 10:46:20 -0000

On Tue, Oct 10, 2017 at 10:23:31AM +0000, Dan Brown wrote:
> ‎http://ia.cr/2017/890 gives a theoretical reason to prefer
> deterministic signatures: some proofs work better. So, my
> question goes to side channels (and subversion too, but less so)
> which is better at resisting them, deterministic or one of these
> tweaks in the 2 eprints below?

I think it depends...

There are environments that do not have to care about fault attacks
as long as the algorithm does not leak the key with random faults
(*cough* RSA-CRT *cough*), e.g. stuff running on general purpose
operating systems. However, such environments might very well care
about other side channels like cache attacks. The value of defenses
proposed by the paper for this are somewhat doubtful, altough those
defenses would prevent trying to repeatedly scan r with the same
message to sign (but proper constant-time algorithm would take care of
that as well).

Then there are environments that do care about fault attacks, like
smartcards. These environments usually care about side channels such as
timing and power analysis too. However, the sensitive parts are
elsewhere, needing additional randomization beyond what was proposed in
these papers.



-Ilari