Re: [Cfrg] Summary of the poll: Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

Adam Langley <agl@imperialviolet.org> Fri, 19 June 2015 21:32 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814CA1B2ACC for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2015 14:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 bRBu7SisKUBf for <cfrg@ietfa.amsl.com>; Fri, 19 Jun 2015 14:32:28 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 E2F441B2ACB for <cfrg@irtf.org>; Fri, 19 Jun 2015 14:32:27 -0700 (PDT)
Received: by lbbti3 with SMTP id ti3so79421318lbb.1 for <cfrg@irtf.org>; Fri, 19 Jun 2015 14:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=DJ+yRv9IwSdPJss8iVo9LwbPYY174Ow4ZRaQU3M8UpM=; b=pQVLtwoUPD46AzRj+eZSB5TYVsOztnBmyHl7WZvpJO2ye/2JQWbHdyvVTf/R9KpH8l Xuw7UBKJtNxSVis8VSaeLuN0KG0MtqHMGp+S8JPk0iRPhr8jmMFUenC4wIKY0MkgvUVU O4EUB/f9WL43qxp4+iFhSHvtUyR3vwUUmo2t/IUyoYnRnT6+/oTYc05WHKLMZ/fnYkkh Hn9I7zwzPdXo9tmC7VWNflwjhwAwLZ7MbyokCsEgw0avBs7BzjUXHhrLNK1nlrpJhj+9 +e4H/etU/w43g1AwbKPtEuo50SLet+O0mnvCYAEuoFRuOaf/F9RfCDLQsjnPoZkkNuwq 3HCg==
MIME-Version: 1.0
X-Received: by 10.112.220.7 with SMTP id ps7mr19400987lbc.72.1434749546350; Fri, 19 Jun 2015 14:32:26 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.89.69 with HTTP; Fri, 19 Jun 2015 14:32:26 -0700 (PDT)
In-Reply-To: <CAA4PzX3Toc+Ev6rp38rU73rinygxGPE7_FLXOWrRMh+N4SPyYQ@mail.gmail.com>
References: <557FEA01.7070207@isode.com> <557FE6E4.3040509@isode.com> <20150619062752.3506.qmail@cr.yp.to> <CAA4PzX3Toc+Ev6rp38rU73rinygxGPE7_FLXOWrRMh+N4SPyYQ@mail.gmail.com>
Date: Fri, 19 Jun 2015 14:32:26 -0700
X-Google-Sender-Auth: iwU5ip21BI-1oDI6Xq6nRm3JUAM
Message-ID: <CAMfhd9Ua=fV_MKMfj1T8dApM6fA7Ko4y8-_uu03dd_WpmK4VvQ@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/QM_aX7tm-8qsSkXM0VbF9SxRIuA>
Subject: Re: [Cfrg] Summary of the poll: Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 21:32:29 -0000

Ponder, for a second, a world in which CFRG specified two schemes:
Ed25519(m) and Ed25519(H(m)).

Also consider a PKI system that issues certificates and CRLs.
Certificates are a type of message and are some serialisation of {0,
name, public-key of name}, where the zero is a single byte that serves
as a "type" indicator. CRLs are another type of message and are {1,
start-time, end-time, list of revoked certificate hashes}.

A signed message is {message, signature-algorithm, signature}.

Now, you might not think that this design is wise, but I would argue
that it's plausible as it's similar to X.509.

I, the attacker, can register a domain name and get a certificate for
it. The CA happens to sign with Ed25519(H(m)), even though the
messages aren't very large. So, offline, I iterate over many domain
names and pick one where the hash of the certificate structure for
that name and my public-key looks like a valid CRL message. I need to
fix the first byte to be one, probably fix a few other length bytes,
and obviously my fake CRL has to be exactly the length of a hash, but
the work-factor is pretty plausible.

Now I register that domain name and get a certificate for it. Then I
construct {message = fake CRL, signature-algorithm = Ed25519(m),
signature = signature from real certificate}. That should validate,
no? If I can construct a valid, signed CRL that covers a wide range of
time then I've broken revocation in this system.

The key here is that the attacker can specify the signature algorithm
and confuse the verifier. X.509 allows exactly this but, even if not,
I suspect that people will use the same key in several different
contexts like that.

So we would need to be careful with Ed25519(H(m)).


Cheers

AGL