Re: [Cfrg] Handling invalid points

"D. J. Bernstein" <djb@cr.yp.to> Tue, 25 November 2014 13:08 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 060481A037B for <cfrg@ietfa.amsl.com>; Tue, 25 Nov 2014 05:08:58 -0800 (PST)
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 3zr7EZSuQYlN for <cfrg@ietfa.amsl.com>; Tue, 25 Nov 2014 05:08:56 -0800 (PST)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id E44181A036E for <cfrg@irtf.org>; Tue, 25 Nov 2014 05:08:39 -0800 (PST)
Received: (qmail 20327 invoked by uid 1017); 25 Nov 2014 13:08:58 -0000
Received: from unknown (unknown) by unknown with QMTP; 25 Nov 2014 13:08:58 -0000
Received: (qmail 24008 invoked by uid 1001); 25 Nov 2014 13:08:33 -0000
Date: Tue, 25 Nov 2014 13:08:33 -0000
Message-ID: <20141125130833.24007.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: <5C83990C-D144-44AC-A5F9-944E499A6F2E@shiftleft.org>
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/hu4U0TV8ytzz7CEZNvTuYr_7KQw
Subject: Re: [Cfrg] Handling invalid points
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: Tue, 25 Nov 2014 13:09:09 -0000

Michael Hamburg writes:
> With a prime-order short Weierstrass curve, (x,y) points transmitted on
> the wire (compressed or otherwise) cannot be the identity

No, it's not that simple. As I wrote earlier: "For cofactor 1 the
implementor has to go digging through obscure, poorly tested code to
figure out how the point at infinity might end up being communicated
(e.g., does the implementation treat input points off the curve as
infinity?) and then represented internally. Isn't TLS actually moving to
something much more confidence-inspiring than such patches, namely
hashing more inputs?"

> The Goldilocks encoding reduces the complexity of dealing with this

No. Checking for output 0 from the Montgomery ladder is guaranteed to
catch all non-contributory inputs for X25519, and is the simplest
imaginable check. (The local factor 8 clears all of those inputs, and
the main theorem says that the ladder always multiplies correctly.)

Further compression---e.g., specifying a constant top byte, avoiding the
top bytes of non-contributory inputs---would move the check inescapably
into the syntax, although it would slow down key generation somewhat.

> behavior should be testable by vectors

Sure. On the other hand, people often put together test vectors that
cover only "normal" cases and not unusual cases. Protocols should be
designed to be robust against likely implementation errors.

---Dan