Re: [TLS] draft on new TLS key exchange

Nico Williams <nico@cryptonector.com> Fri, 07 October 2011 21:06 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23B21F8C2A for <tls@ietfa.amsl.com>; Fri, 7 Oct 2011 14:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level:
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvbI3JtQc4x8 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2011 14:06:32 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF721F8C0C for <tls@ietf.org>; Fri, 7 Oct 2011 14:06:32 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id E19405406F for <tls@ietf.org>; Fri, 7 Oct 2011 14:09:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Ph1AufuGmPrlpj4YmX1WfUh1qH1z2ONvTi41jxhkeYoV 3p4OAfCpmT+ftmEkWt8+brGv/zj9zcBfslJkhnhTEfS1yYiT7sZpt1Z3tQikNGxL kCMrJwAPqf676JOeXVJOfMLM+t39WQp5CWSw02iMGj+F3UbCgMTCdpAEqwt9iNk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ZpDGO5IhGMlv9DoYwZZP8rHJThA=; b=vWOT36/TNo5 RKo2dPHIWZGFyy1GXg66L+9Mow9BLsR6i5DFIYwlyl2V1hxeGPdJX9xvHAe2sUmA JKjJbl/GH3meIWPSb0Vl6D0kZe5uhIBy92lkQmQ37IEBwhiWOJDWFxgqvPt5e+ht hwKuDl64K/cGZvqTC89dAjzVLeOedPq4=
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id BC7D45401F for <tls@ietf.org>; Fri, 7 Oct 2011 14:09:25 -0700 (PDT)
Received: by ywm3 with SMTP id 3so4877004ywm.31 for <tls@ietf.org>; Fri, 07 Oct 2011 14:09:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.35.232 with SMTP id l8mr16413025pbj.75.1318021764251; Fri, 07 Oct 2011 14:09:24 -0700 (PDT)
Received: by 10.68.59.169 with HTTP; Fri, 7 Oct 2011 14:09:24 -0700 (PDT)
In-Reply-To: <4E8F4797.9000008@gmail.com>
References: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp> <4E8F4797.9000008@gmail.com>
Date: Fri, 07 Oct 2011 16:09:24 -0500
Message-ID: <CAK3OfOhxpwpvFiMwhA0e6fGS9tKD5eBD5BEW4FkDOae6hr5h4A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Rene Struik <rstruik.ext@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org, dhalasz@intwineenergy.com
Subject: Re: [TLS] draft on new TLS key exchange
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2011 21:06:32 -0000

On Fri, Oct 7, 2011 at 1:40 PM, Rene Struik <rstruik.ext@gmail.com> wrote:
> 2) the mapping from passwords to elliptic curve points.
>
> As to #2, indeed, the procedure in Section 4.1.1 for mapping a password to a
> point on the curve ("hunting and pecking") has indeed a non-deterministic
> running time, due to “trial-and-error” approach and may, therefore, by
> vulnerable to a side channel attack. Note, however, that there are also
> deterministic methods for mapping a a value to a curve as introduced, e.g.,
> in the Crypto 2010 paper by Icart, Coron, et al (cf. also IACR ePrint
> 2009-340) and the CRYPTO 2009 paper by Icart et al. The CRYPTO 2009 paper
> discusses the probabilistic method Dan Harkins describes (cf. Section 1.1 -
> Try and Increment Method; Section 5 - Practical Implementations). Table 1 of
> Section 6 (Try and Increment v3) provides results for an implementation that
> supposedly prevents potential leakage of information from determining
> whether x^3 + a x + b is a quadratic residue in GFp via the Legendre symbol
> computations. Thus, that paper suggests that side channel resistance can be
> dealt with, at the expense of time latency. The paper also illustrates that
> the deterministic method for "hashing to a curve" has better performance
> (again, refer to Table 1 of Section 6 of the CRYPTO 2009 paper).

Curve25519 is trivial to generate private keys for.

"Security Analysis of the PACE Key-Agreement Protocol", by Jens
Bender, Marc Fischlin, and Dennis Kügler discusses and refers to
papers about hashing to point values.

I like and recommend recommend PACE.

Nico
--