IETF Logo Mail Archive

Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems

Watson Ladd <watsonbladd@gmail.com> Tue, 17 March 2015 16:05 UTC

Return-Path: <watsonbladd@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 E254C1A8716 for <cfrg@ietfa.amsl.com>; Tue, 17 Mar 2015 09:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 zN-zm8ljt622 for <cfrg@ietfa.amsl.com>; Tue, 17 Mar 2015 09:05:44 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (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 50F481A8713 for <cfrg@irtf.org>; Tue, 17 Mar 2015 09:05:44 -0700 (PDT)
Received: by yhjf44 with SMTP id f44so5051390yhj.3 for <cfrg@irtf.org>; Tue, 17 Mar 2015 09:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=V2gOVB9AiJJbS1bR0qHHw8U2mMfmuYPV6m/PUZzhKcY=; b=lzEHzjUxvNwbZM1VPY/NScdM7sPFpBWTA34C6DzQK+EJYOUjjLdRQi1v44H6v8cxvr kcKU9zjJSXrox+Kxy+evmaWyH+b8p6sEhkY4AJFcPAGUMBnmMI0E/gkUOpoNiIGU6kV6 DIPidf4IrsMFn/3EUWsPh2OSJAApfHnET/uFbQklVyUnHylOt3Ia/ob0p9Ez5ARMUOAV cM6TaDwIbaw16Vj/9H+S1HAg9n6XENmjj2iAcqY6GLJiRxBnu7H6n7AsJ9WwcCTlgnj6 f3N+Ijdw0cYhkB3fE6oVLPVzegcqpWrM6EQv4wB5AJS/eXaxm4POmVPC6hpJptJAZET8 J/tg==
MIME-Version: 1.0
X-Received: by 10.170.185.133 with SMTP id b127mr51474736yke.28.1426608343610; Tue, 17 Mar 2015 09:05:43 -0700 (PDT)
Received: by 10.170.58.201 with HTTP; Tue, 17 Mar 2015 09:05:43 -0700 (PDT)
In-Reply-To: <20150317004810.GF3223@mournblade.imrryr.org>
References: <5501E6A5.5040608@brainhub.org> <A6F30412-8E0A-4D8D-9F26-580307B46874@shiftleft.org> <20150316002255.28855.qmail@cr.yp.to> <20150316044906.GA27479@mournblade.imrryr.org> <5506D5BB.3090700@gmail.com> <20150316135620.GC27479@mournblade.imrryr.org> <5506EF80.7010809@gmail.com> <CACsn0ck6EY1PVB39a6gTxrnxgPTY_quMRGya2jm79CsH4iLC4Q@mail.gmail.com> <20150317004810.GF3223@mournblade.imrryr.org>
Date: Tue, 17 Mar 2015 09:05:43 -0700
Message-ID: <CACsn0cnte5WtJ7C8OD14FKdoXxrESCNnKZozHNDtFP5aW+sxQQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/4ohNAHf3zzGs9wgDOA-ZQNkKCCM>
Subject: Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems
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, 17 Mar 2015 16:05:46 -0000

On Mon, Mar 16, 2015 at 5:48 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Mon, Mar 16, 2015 at 08:39:06AM -0700, Watson Ladd wrote:
>
>> Of course, we've always described what's required to ensure contributory
>> behavior in Curve25519, and it's always the case that implementors
>> should know what the protocol requires as far as assuring contributory
>> behavior, namely rejecting 8 inputs. TLS is really the odd man out in
>> requiring contributory behavior.
>
> If I recall correctly it is simpler to reject the corresponding
> single output (namely 0) than the 8 inputs that map to zero.
> Admittedly my memory of the details is a bit fuzzy on this...
>
> Since the output is sensitive, all one has to do is a constant-time
> memcmp of the output with a 256-bit zero.
>
> Does TLS need to defend against this?  It is not obvious that it
> does.

Yes, it does. This is the Triple Handshake variation I posted to the
TLS list about some time ago. Of course, properly designed protocols
don't have these problems, and protocol designers who aren't capable
of determining if contributory behavior is required, and changing the
protocol so it isn't, probably shouldn't be trusted to design
protocols where these things matter.

Sincerely,
Watson Ladd

>
> --
>         Viktor.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

v2.23.0 | Report a Bug | By Email