IETF Logo Mail Archive

Re: [Cfrg] Why zero checks?

Nick Mathewson <nickm@torproject.org> Fri, 27 March 2015 16:30 UTC

Return-Path: <nick.a.mathewson@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 2DC9D1A8756 for <cfrg@ietfa.amsl.com>; Fri, 27 Mar 2015 09:30:56 -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 euSCJ_aO4IYy for <cfrg@ietfa.amsl.com>; Fri, 27 Mar 2015 09:30:55 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 283A01A7035 for <cfrg@irtf.org>; Fri, 27 Mar 2015 09:30:50 -0700 (PDT)
Received: by lagg8 with SMTP id g8so74563380lag.1 for <cfrg@irtf.org>; Fri, 27 Mar 2015 09:30:48 -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:cc:content-type; bh=991e1noIsLk4o7qWUKrHp4S/FAmTTqHJxZO0xGxdoVw=; b=idQDB29HuhIRboo866yqhFxPHgpZsJXATa1gzSa30I8oZRP6fnSTXFxyEtb79ICPBa 7BesLhLQ4aBnAIERRPp62luaUlxxx2sbuIwRPUa/JeTTS0/KXZA/0QSVSF7pP0YZYrZ5 o3T7gQVVevGPlegUEb0qCcSGOU/7mggy7njH4dvbFtc1tPcA1Pv1ULNsRNSIgqZJIWyE 5HlU8rWsQ+lF2V0PINmyyd7huvsGErmCtjSXWueSsP/+fudheRgKFEZYS/nnPyguEoWc jJfI0jJrfbPY2EeeDzxLljHZWViTcY3kZBvyMXK5J8sI+zyRFZztym4VbnMv1upgcS1o dPxQ==
MIME-Version: 1.0
X-Received: by 10.112.12.134 with SMTP id y6mr18814790lbb.34.1427473848512; Fri, 27 Mar 2015 09:30:48 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.112.219.234 with HTTP; Fri, 27 Mar 2015 09:30:48 -0700 (PDT)
In-Reply-To: <CAK9dnSzXr8-7YoexPMn+gotPsCLvRtuV4a38S174Gm4UPMECKw@mail.gmail.com>
References: <CACsn0cnsYxzs4CZsstmRqBgeeiagDg6cCxzxo5BV2nSEA6jvTw@mail.gmail.com> <alpine.BSO.2.11.1503261429550.22200@natsu.mindrot.org> <CAK9dnSzXr8-7YoexPMn+gotPsCLvRtuV4a38S174Gm4UPMECKw@mail.gmail.com>
Date: Fri, 27 Mar 2015 12:30:48 -0400
X-Google-Sender-Auth: 8P4opvFeVXVdYbL2H3NV8uu1XYc
Message-ID: <CAKDKvuzD06mQpaViv5=GfdoeJRmk0aAD68ABuTH7EF+TrD0uPw@mail.gmail.com>
From: Nick Mathewson <nickm@torproject.org>
To: CodesInChaos <codesinchaos@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/5OtOllwdK6omZ7cS0F22nFa4acU>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Why zero checks?
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, 27 Mar 2015 16:30:56 -0000

On Fri, Mar 27, 2015 at 11:01 AM, CodesInChaos <codesinchaos@gmail.com> wrote:
> It may be cheap performance wise, but it's not cheap API wise. It
> turns an API that always succeeds into an API with error conditions.
> One of the main selling points of the common Curve25519 APIs is that
> they simply work. I strongly dislike pushing this down to primitive as
> a requirement.
>

As an application developer, I have a slightly different concern.

Even if we take Adam's recommendation here and make the function *not*
have an error condition (by making it return a random value instead),
we'll still be forking the ecosystem of curve25519 implementations so
that some will check for zero and some won't.

Any applications that come to rely on the behavior specified here will
reach an unpleasant outcome when they try to use (most of) the
existing curve25519 code.

Perhaps suitable naming of functions could solve this in practice?  Or
a differentiation between the "DH" and "DH-and-check" functions?

-- 
Nick

v2.23.0 | Report a Bug | By Email