Re: [Cfrg] Security proofs v DH backdoors

Ilari Liusvaara <> Sun, 30 October 2016 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33C1F12951C for <>; Sun, 30 Oct 2016 04:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0pRDg2H66ABn for <>; Sun, 30 Oct 2016 04:13:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2DC931294A5 for <>; Sun, 30 Oct 2016 04:13:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 095CC12F7F; Sun, 30 Oct 2016 13:13:00 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id Q6WCvY1vjv6Y; Sun, 30 Oct 2016 13:12:59 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9DD372313; Sun, 30 Oct 2016 13:12:59 +0200 (EET)
Date: Sun, 30 Oct 2016 13:12:57 +0200
From: Ilari Liusvaara <>
To: Peter Gutmann <>
Message-ID: <>
References: <> <> <> <> <> <20161027125120.4d260334@pc1> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: CFRG <>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Oct 2016 11:13:03 -0000

On Sun, Oct 30, 2016 at 10:56:48AM +0000, Peter Gutmann wrote:
> Michael Scott <> writes:
> >As an influential opinion leader I think you really need to expand on that
> >last paragraph. In the first sentence you need to define "harsh environment".
> >The second sentence ("any fault of any kind") is manifestly untrue. And in
> >the third sentence what industries exactly?
> So I've been sitting here trying to figure out how to respond to this (and one
> or two other messages).  I think there must be some sort of miscommunication
> happening because I can't otherwise explain why you're asking what you are.
> The options seem to be:
> 1. You're unaware of how vulnerable to faults ECC is.
> 2. You're unaware that computers experience faults.
> 3. We're talking at cross purposes/miscommunicating in some way.
> Before I type up a long essay on #1 or #2 (which I'm not terribly keen on
> doing) I want to make sure that you're really asking what you appear to be
> asking, and one or both of us hasn't misinterpreted the others' position.

Is ECC even more vulernable to faults than e.g. RSA-CRT? AFAIK, release
even _one_ any way faulty signature computed using RSA-CRT and your
private key walks.

It is so bad that most implementations using RSA-CRT internally
verify the generated signature first. Even if not operating in any sort
of "harsh" environment.

I certainly haven't heard anything similar for ECC. Fault key recovery
attacks yes, but those at least required some degree of control over
the faults, not "one random fault and key walks" RSA-CRT has.

For determininistic ECC signatures, computing the signature twice and
comparing is cheaper than verifying it.