Re: [Cfrg] Security proofs v DH backdoors

Michael Scott <mike.scott@miracl.com> Sun, 30 October 2016 17:49 UTC

Return-Path: <mike.scott@miracl.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 997A91293D9 for <cfrg@ietfa.amsl.com>; Sun, 30 Oct 2016 10:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miracl-com.20150623.gappssmtp.com
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 Mwck6_9p8eJt for <cfrg@ietfa.amsl.com>; Sun, 30 Oct 2016 10:49:47 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8659012946B for <cfrg@irtf.org>; Sun, 30 Oct 2016 10:49:47 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id i127so180789061oia.2 for <cfrg@irtf.org>; Sun, 30 Oct 2016 10:49:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miracl-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7jmij9/BI9qObsdDoHiYxB1FdVix7eQHQspyHvluAmc=; b=lgSLc/4MRhI8sWyWhrOEzpK+qb32zqzk8WxOHoEwiC/T908DlYitSsVqwBp50TroQu NnO1v4AK6JJsTFpFCcSvEVT/XQ9Iv5mVhDvqi++GhAxpnA8wVtMjJlYagdg1pZs6QMZI 4OnoGIJna7bflaTAiT67SrC86/S2FpfayCD02YWp9S+FcMk65V1Oo9QteYiPJsEVkChS g5ehqRqL5CINzlYSjMIY3/ljpeIA1mqCthhfKe6mngyflHwqx09hx3+ca/rONpz1JnC8 6AG4nYosi84Xu5FYoN01EppqNFx6lpp+7HQpKDMJWWmVlihJJN0K9hvM0LWgbQrBiCK5 0cbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7jmij9/BI9qObsdDoHiYxB1FdVix7eQHQspyHvluAmc=; b=SY3rAEiVl2kHApUO+3ycxV9RVYbhM2652d9hC8srpdupaCbv31A34BvEzuTOoKZE37 ebFmBO41/teXN6VBMtWxwo+Rb/93vBIFByFqXWMEYL/H33N3bRaVt8QRHSR4vJmLwYl3 1hOOMfGhwc9j8AIW8LASKEBPPfmaM91I198mEi+9Zigc3jyUtfR6H5xDBNWVKFFq+Rbz S+erwK03CS+owjetcnAbSRRHUh2KbYlvXRi/DmQAgHxoNaRhCduUBJUuvY3xhmMKp7Bf xfqAf16XkxresxyBratePF+eDFdTLCUp6Zvf0iYnq334SqwXytLQJg701at2Hh8vZoXi 2vIw==
X-Gm-Message-State: ABUngvd10TMKfjWj5rAsGTZ8O2nwngTG4aiTqkTpNOzDPqXfF06HiQa0A7p9XWRmLQUkzkW3ht1YMMmpaUty5mAo
X-Received: by 10.36.58.204 with SMTP id m195mr5816230itm.81.1477849786599; Sun, 30 Oct 2016 10:49:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.153.83 with HTTP; Sun, 30 Oct 2016 10:49:45 -0700 (PDT)
In-Reply-To: <1477824996551.98206@cs.auckland.ac.nz>
References: <20161025131014.5709905.2866.6563@blackberry.com> <20161025133016.GA9081@LK-Perkele-V2.elisa-laajakaista.fi> <1477456366629.49872@cs.auckland.ac.nz> <44595.1477524032@eng-mail01.juniper.net> <20161027103214.5709905.11728.6650@blackberry.com> <20161027125120.4d260334@pc1> <1477647359860.49982@cs.auckland.ac.nz> <CAEseHRpN94UWT+rPUbyxsZp8ToKYQR=3=Qn0qt_Kdn27Y6iwxg@mail.gmail.com> <1477824996551.98206@cs.auckland.ac.nz>
From: Michael Scott <mike.scott@miracl.com>
Date: Sun, 30 Oct 2016 17:49:45 +0000
Message-ID: <CAEseHRqMXBN7MbZh53Rc_zNncG1OHKXHJYoNOFW0kAYoYBbDkw@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=001a11441e1e8fe0c9054018b7cd
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/v2hyS4Qx2yID2D12PZN20lwStv4>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Sun, 30 Oct 2016 17:49:50 -0000

Its dead simple really (so surely must be a miscommunication). For example
you said that "any fault of any kind inevitably ends up leaking the
private key".
This is a technical group, so I expected that this was not some rhetorical
flourish, but you meant exactly what you said. In hindsight (and here is
the miscommunication) it probably was meant as a rhetorical flourish.

A beginner reading that comment might assume that all they have to do is
induce any fault at all anywhere in an ECC binary, and out will pop the
private key. So no reverse engineering required to determine where to
induce the fault, just whack it anywhere.

In my experience the vast majority of "any faults" just cause the program
to rather boringly crash, not revealing nothing to nobody.


Mike


On Sun, Oct 30, 2016 at 10:56 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Michael Scott <mike.scott@miracl.com> 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.
>
> Peter.
>
>