[Cfrg] Random curves according to Auerbach--Bellare--Kiltz

Dan Brown <danibrown@blackberry.com> Mon, 08 January 2018 18:19 UTC

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
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
Precedence: list

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

[Cfrg] Random curves according to Auerbach--Bella… Dan Brown