[Cfrg] Random curves according to Auerbach--Bellare--Kiltz
Dan Brown <danibrown@blackberry.com> Mon, 08 January 2018 18:19 UTC
Return-Path: <danibrown@blackberry.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 4E2BF12D7EC for <cfrg@ietfa.amsl.com>; Mon, 8 Jan 2018 10:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level:
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 WD_5GTFQ8PPc for <cfrg@ietfa.amsl.com>; Mon, 8 Jan 2018 10:19:01 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D92A12D7E9 for <cfrg@irtf.org>; Mon, 8 Jan 2018 10:19:00 -0800 (PST)
X-Spoof:
Received: from smtp-pop.rim.net (HELO XCT104CNC.rim.net) ([10.65.161.204]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jan 2018 13:18:59 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 8 Jan 2018 13:18:59 -0500
From: Dan Brown <danibrown@blackberry.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Random curves according to Auerbach--Bellare--Kiltz
Thread-Index: AdOIqm7aRQv/qIq5S4KF7ASQa6LZuQ==
Date: Mon, 08 Jan 2018 18:18:58 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501C0BCAE@XMB116CNC.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ma2fE2LbGJvTkvgAypm2PZ8Wwe0>
Subject: [Cfrg] Random curves according to Auerbach--Bellare--Kiltz
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Mon, 08 Jan 2018 18:19:03 -0000
Dear CFRG, In https://ia.cr/2018/023 (and IACR-PKC-2018?), Auerbach, Bellare and Kiltz describe using random curves to avoid the threat of subverted parameters. I've not yet read the whole paper, so am only 10% sure what they're really proposing. The gist seems to select a random curves at the time one generates a public key, for PKE or KEM, etc. I'm not sure they propose doing SEA for each curve, or just to eliminate curves with too many small-order points. Presumably, the ephemeral side needs to be able to implement an arbitrary curve (over a fixed field, or a fixed field size, etc.). This would slow down some steps, but might still be fast enough for some IETF applications. I don't see (at all) how this address signatures and PKI issues (PKE and KEM rely on some kind of trust), so the (theoretical) threat of subverted parameters still remains. Best regards, Dan Brown PS: it's still on my to-do (/overdue) list to describe here how I would choose fixed pseudorandom parameters (in ECC or elsewhere).