Re: [Cfrg] Security proofs v DH backdoors

Antonio Sanso <> Mon, 31 October 2016 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0210712958D for <>; Mon, 31 Oct 2016 02:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ND1GF4sK1MQj for <>; Mon, 31 Oct 2016 02:21:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDD1C129584 for <>; Mon, 31 Oct 2016 02:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkWHSY2kfPVBF08acHFbFOrGMa8ScybxEj6CojkJyUc=; b=mLXGMUqHJGyxOumdoUI3qoWEn/t4PMPsx4phqUpr2kqZhF/Y7Sk/srJBdH2SM0Alu4aMRy3xPRfIo3L+3GvT/UeQ1Ou34HI2ECkRGG4LtHDb+8p87gm9T+wkIzgcFtAXAw63zpGoPyzSTu4Cv6WrvP45ffuBNQB21E+iBqbZCJE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Mon, 31 Oct 2016 09:21:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0693.009; Mon, 31 Oct 2016 09:21:23 +0000
From: Antonio Sanso <>
To: Peter Gutmann <>
Thread-Topic: [Cfrg] Security proofs v DH backdoors
Date: Mon, 31 Oct 2016 09:21:23 +0000
Message-ID: <>
References: <> <> <> <> <> <20161027125120.4d260334@pc1> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: f837ae4d-c452-436e-da8e-08d4016f48b8
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 7:JrNZIGEGExN8nAfml/HSwqHEIntw6OONUnyF9/ITCyHAATlm9uqqNHERYAgIiP2VSV9fKIA/7Z/yh7kXqBHuZByAUeMdUdYJBAemknYXLlfa8uNHF3malajUhq1g4PUMzpI2E33QRNn+URcErBtfcJTLq55mPyA5YWzui9QV4dygyw0uc8fS3KeJfUs32popEzReWFOwetyKanoQNzOE1X9Pwq18zJBJU5hcBecbfqtc72MTzwTh45z5lMiNbTPjIKeolwcQdz+1shLBmkWXsZ73yBBMnobJwfybZnCHFZ6+TaoQTXdg/rVOAdFw8HAAcFyvRC4VG8J9+3EOJXweWiw0svGC836UnLoH+Wv58rY=; 20:ILZNyOKKp2Oa4Dd+sR0HNXy0G9RzMjUi9idnuub7NXuC7iIjBMJZByZtRly/pFRNx0J9caVwkkXTxI/GJ2LP1T8XRyz7Syp0lwHp0+/DGYUSodPC+uTz6WgQp3i4SrUoiBOh9HgXrZ2Djg8Jc+zV/nJLixSbUig3d6GKtCVYVLM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029;
x-forefront-prvs: 01128BA907
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(377454003)(24454002)(81166006)(11100500001)(10090500001)(33656002)(586003)(92566002)(105586002)(7846002)(8676002)(2900100001)(99286002)(305945005)(106356001)(189998001)(15975445007)(81156014)(7736002)(82746002)(5002640100001)(87936001)(83716003)(36756003)(3660700001)(4326007)(93886004)(97736004)(3280700002)(5660300001)(8936002)(6916009)(2950100002)(2906002)(66066001)(110136003)(68736007)(77096005)(19580405001)(76176999)(50986999)(54356999)(10400500002)(122556002)(86362001)(6116002)(101416001)(102836003)(3846002)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 09:21:23.5321 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029
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:21:29 -0000

hi Peter,

On Oct 31, 2016, at 10:13 AM, Peter Gutmann <> wrote:

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

isn’t this a consequence of the reuse of GCM n-once rather than ECC fault?



>> 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.
> Peter.
> _______________________________________________
> Cfrg mailing list