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

"D. J. Bernstein" <djb@cr.yp.to> Fri, 22 May 2015 09:30 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 A85081B2AAA for <cfrg@ietfa.amsl.com>; Fri, 22 May 2015 02:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.896
X-Spam-Level: **
X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, UNPARSEABLE_RELAY=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 52K-gVjIsn8e for <cfrg@ietfa.amsl.com>; Fri, 22 May 2015 02:30:11 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id D13221B2AA7 for <cfrg@irtf.org>; Fri, 22 May 2015 02:30:10 -0700 (PDT)
Received: (qmail 5113 invoked by uid 1017); 22 May 2015 09:30:29 -0000
Received: from unknown (unknown) by unknown with QMTP; 22 May 2015 09:30:29 -0000
Received: (qmail 4601 invoked by uid 1000); 22 May 2015 09:29:59 -0000
Date: Fri, 22 May 2015 09:29:59 -0000
Message-ID: <20150522092959.4599.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <CACsn0ck8gTCWqt+B7vOKQVzBrUkxW5YJgkDQ+9eJQrDFeTM8rA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/bD71Izzz5mM_DIHLcDNahT2xk_U>
Subject: Re: [Cfrg] 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, 22 May 2015 09:30:12 -0000

Watson Ladd writes:
> It seems as though determinism, one pass schemes, and avoiding
> collision resistance are at odds, unfortunately

Probably one can split a message into

   * packet p0 plus a signature s0 of ("start",p0);
   * packet p1 plus a signature s1 of ("middle",s0,p1);
   * packet p2 plus a signature s2 of ("middle",s1,p2);
   * ...;
   * last packet pn plus a signature of ("end",previous s,pn).

I'm saying "probably" because this sort of thing needs formal security
analysis. But it's known how to do this sort of analysis, either
producing an attack or producing a convincing proof of security.

This is deterministic. It's resilient to collisions in the underlying
hash function. It's one-pass. Most importantly, it allows a one-pass
verifier to immediately reject any forged packet. The attacker can
truncate at any point---and sometimes this by itself is a big problem,
inherent in the concept of streaming, worse than having no message at
all---but (assuming the security analysis works) the attacker can't
forge any packets.

On the other hand, since the fans of streaming crypto interfaces have a
long history of building "verification" software and hardware that
blithely spews out forged packets directly from the attacker into other
components that can't handle it, I'm not sure what exactly is being
accomplished by providing a cryptographic algorithm that _can_ remove
all forged packets. Is the cryptographic user supposed to suddenly start
trusting these interfaces?

What _definitely_ improves security is switching to the much more robust
world of all-in-one crypto interfaces. In this world streamability is
clearly a bad idea: it provides no benefit, and trying to secure it
creates a serious cost in simplicity (not to mention performance).

More to the point, it's clear that these decisions should be made at a
layer above the basic signature algorithm. The basic algorithm---the
algorithm that everyone should use by default---should not allow
security and simplicity to be corrupted by the pursuit of streaming.

---Dan