Re: [Cfrg] Security proofs v DH backdoors

Peter Gutmann <> Mon, 31 October 2016 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AB0F12957E for <>; Mon, 31 Oct 2016 02:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h4J3U-xqhlWj for <>; Mon, 31 Oct 2016 02:14:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B7570129579 for <>; Mon, 31 Oct 2016 02:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1477905244; x=1509441244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MBRMac/chxULWc7fS1qFroHm4HWjZ1V64YKZ8l6XWq8=; b=jESLqsmGgxCuhKiwPn/pdGw0yBGzovOunBV5IzLh0c95Zec26AipFJGb rCFDXQ0xQqdkGy+fmFvp/nd35ENdH+8GcxdeepjkDOIqhNSklBXCiQYTY ZGR928zmc3Uv5nyMrcruWOSgDAnu5CNqZ1Nv8KYM6EZs9fz8hw5vk8Ei7 nQ3YbPl/X67M0z4+8qD30QCFyQcxmm3I1PPmsd7Yn2AcQnWhJy95+wAay C5pQhWMgrrB3m6Rg8rYj3tT3y9gjsaIZ++nh613wdNAMm2NKZVOwKVsj9 rjDBmkb6WKg0rOlDdUvKKACeanYMDUcRndcJ4FPneYg4R1VxVYUtTW05R Q==;
X-IronPort-AV: E=Sophos;i="5.31,426,1473076800"; d="scan'208";a="112829815"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 31 Oct 2016 22:14:00 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 31 Oct 2016 22:14:00 +1300
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Mon, 31 Oct 2016 22:14:00 +1300
From: Peter Gutmann <>
To: Michael Scott <>
Thread-Topic: [Cfrg] Security proofs v DH backdoors
Thread-Index: AQHSMEAWZy2e+SPalEyp/G+CJ2BAv6C9nFXG//8rFoCABBBRCf//mdWAgAHarQs=
Date: Mon, 31 Oct 2016 09:13:59 +0000
Message-ID: <>
References: <> <> <> <> <> <20161027125120.4d260334@pc1> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 31 Oct 2016 09:14:10 -0000

Michael Scott <> writes:

>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.

Yeah, it was just general complaining about the brittleness of ECC (and some
of the other mechanisms it's used with).  At one end of the scale you've got
some pretty bulletproof/abuseproof modes, CBC with HMAC and -PSK, to which you
can do almost anything and mostly just end up with data corruption
(pathological worst-case with CBC, if you memset() the IV to all-zeroes on
each block, is degradation to ECB), while at the other end of the scale you
have ECC + AES-GCM, a simple fault in the RNG (so repeated k, repeated
counter) means you lose the ECC private key, confidentiality, and integrity-
protection, all in one go.

>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.

I think they're probably going to realise it's not as simple as that :-).

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

If there's a fault and it's unhandled, the watchdog restarts the system.  In
fact that's a standard error-handling strategy, fail-fast, go into an endless
loop until the watchdog restarts the system and the error is cleared.