Re: [Cfrg] using hash2curve in a protocol

Dan Harkins <dharkins@lounge.org> Sun, 11 August 2019 02:39 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469F0120993 for <cfrg@ietfa.amsl.com>; Sat, 10 Aug 2019 19:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 oKF8PLAxNhA0 for <cfrg@ietfa.amsl.com>; Sat, 10 Aug 2019 19:38:43 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64C31208FA for <cfrg@irtf.org>; Sat, 10 Aug 2019 17:25:57 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PW1007CMQJ8BU@wwwlocal.goatley.com> for cfrg@irtf.org; Sat, 10 Aug 2019 19:25:56 -0500 (CDT)
Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PW100A1RQIHD5@trixy.bergandi.net> for cfrg@irtf.org; Sat, 10 Aug 2019 17:25:30 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sat, 10 Aug 2019 17:25:30 -0700
Date: Sat, 10 Aug 2019 17:25:51 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <CAFXAJYwem=yiMB0Jd+AKaLkQfGLqiVoNm9cqrD3wfrw3qkjeGw@mail.gmail.com>
To: Mathy Vanhoef <vanhoefm@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Message-id: <0d8aa075-a1cd-cb5b-c45e-aa24def249b5@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local)
References: <8f8cb405-b534-c0ff-d351-3951fef62725@lounge.org> <CACsn0c=jOStaHXpREY9fJM3K88JAdQdY4UKdtzmEOoK65osCCw@mail.gmail.com> <CAFXAJYwem=yiMB0Jd+AKaLkQfGLqiVoNm9cqrD3wfrw3qkjeGw@mail.gmail.com>
X-PMAS-Software: PreciseMail V3.3 [190808a] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/N-3MdwWlwEhvwZZQK10XMTsAvYg>
Subject: Re: [Cfrg] using hash2curve in a protocol
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Aug 2019 02:39:39 -0000

   Hi Mathy,

On 8/10/19 8:57 AM, Mathy Vanhoef wrote:
> I echo the advice that using an existing PAKE is likely the most
> secure option, since these are more well-studied,

   It is an existing PAKE.

> Because similar changes are also being proposed in an update to the
> Wi-Fi standard, one remark is that in the simplified_swu and
> hash_to_ffc routine you can use PBKDF2 or similar instead of HKDF.
> This will make possible brute-force attacks (e.g. due to
> implementation issues or other side-channels) more costly. Since these
> routines only have to be executed when configuring the password, and
> not in every run of the handshake, the added overhead should be
> manageable.

   This is actually more of a comment for the hash-to-curve I-D. I'm
just going to use the techniques defined in that (soon to be) RFC.

   regards,

   Dan.

> Best,
> Mathy
>
> On Thu, Jul 25, 2019 at 3:20 PM Watson Ladd <watsonbladd@gmail.com>; wrote:
>> On Wed, Jul 24, 2019 at 11:05 AM Dan Harkins <dharkins@lounge.org>; wrote:
>>>
>>>     Hello,
>>>
>>>     The hash-to-curve draft is still a work in progress but I want to
>>> use it to fix a broken protocol. The protocol in question is EAP-pwd
>>> defined in RFC 5931. It does a "hunting and pecking loop" method
>>> of hashing to a curve that is similar, but worse, than the technique
>>> described in RFC 7664. (The method of obtaining a secret element in
>>> a MODP group is similarly broken). It is susceptible to side channel
>>> attack and I want to use the hash-to-curve draft to fix it.
>> Why not use a PAKE that comes out of the competition? And are you sure
>> the result of your chosen modification is actually secure?
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg