Re: [Cfrg] A downside of deterministic DL signatures?

Alyssa Rowan <akr@akr.io> Tue, 29 July 2014 21:53 UTC

Return-Path: <akr@akr.io>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51211B286C for <cfrg@ietfa.amsl.com>; Tue, 29 Jul 2014 14:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 PzQRCPjWSq9F for <cfrg@ietfa.amsl.com>; Tue, 29 Jul 2014 14:53:23 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD611B281C for <cfrg@irtf.org>; Tue, 29 Jul 2014 14:53:22 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <20140729205846.6639765.71649.17355@certicom.com>
References: <20140729205846.6639765.71649.17355@certicom.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Tue, 29 Jul 2014 22:53:16 +0100
To: cfrg@irtf.org
Message-ID: <258124fc-3f8b-4ea3-9f61-20395e7916c9@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4TPhndX17Y03QqcV7TFynddlK78
Subject: Re: [Cfrg] A downside of deterministic DL signatures?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2014 21:53:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 29 July 2014 21:58:47 BST, Dan Brown <dbrown@certicom.com> wrote:
>‎In ECDSA or Schnorr, if the ephemeral private key k depends on the
>message bring signed, precomputation of kG, an efficiency advantage
>(reduced latency?), and possibly effective side channel countermeasure
>(harder to time precomputation), seems precluded. Not being an
>efficiency or side channel expert, I ask: Does this downside sound
>right?

On the other hand, deterministic signatures can have test vectors - a big win - and they don't need an RNG. Less baggage, less worry about implementation fingerprinting or even potential kleptography (although obviously you should always avoid black boxes too where that last one could be a risk!).

You also obviously have to store precomputed values around if you choose that (of course you have to keep the key around too, but you're probably not writing that as frequently).

Conversely, you may need to be careful about leaking lengths in deterministic forms like RFC 6979. (Moot if they're visible anyway, but still worthy of mention.)

Deterministic is the most sensible implementation choice. In fact, it's how you SHOULD do it, I think. But having a perfect RNG also works, so I wouldn't on balance make deterministic a MUST: but random k is the most hazardous choice overall, as you're just 2-4 predictable bits away from the precipice of disaster. (...if anyone chooses that route, scrutinise it.)

There's also the hybrid approach chosen by BoringSSL (and current LibReSSL), which depends on RNG and the message. No test vectors possible, but still a hedge against RNG imperfection.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJT2BfMGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6EGgP/iyQhs8oVALu0FDCS3ygoIQ9esLybYjm6wwf6f7BE6/ZoOuFT/5f
ZOcqh8eeqEhbCV8j+3K8G1a7d5ubf3biN2QkZvq/u5Ka81uzJv48IvOY49LEmVKZ
gCpQhXmIUDKYO9mxMahjBAksWr95XVmOXzSDebD9AiYWXwboIAYZMaempnLsfKkZ
AjAMAnJHOM8aMo60N46LQe2Le2ujLNJVlUjTAt14D9HYfgOsEuZrhMS6y1yWvNQW
eoPcDl+09GiKnVpoxtGMhoOF+rnE83rIX/98tvQrn019o4atqfQ8UuHejKoQAZTE
4gtjXHWLKVoSb6z3L+yLxSdsTd6kFukYPcqsiJJZk4NctOQ7TPSA0iyKE7IM0Sbi
C+paPR/B4QXaFtGT9Y3p4Y6E5t/2bx5j7+gc5RXpc9V2c/3Rd7rfJjfoBAAAGM2E
kNlFgKgMIPSx+IGK/iVimTctbBYH2qmZyz7IoGTtUtMqB3CUbyWsNk80t6r+5HhE
kaDf1p12bGz6Fj156fBBqYgOgQJi+NwQVhz/OSu2EQhg4IGgR6FONIAWOGPbITR3
3tKdHnzaN4ZBF0IilpS2Z2CEpvy0kMrV3E136CCShsVMD5+eaUxaZiaSqRykecHC
uGRl+GFfholRtBZqbdGt4hBB0X5PRIqZZ5dZF6hQqE7qtsjyY2mLGVnU
=egg8
-----END PGP SIGNATURE-----