Re: [Cfrg] using hash2curve in a protocol

Björn Haase <> Wed, 24 July 2019 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0DDA1202A7 for <>; Wed, 24 Jul 2019 14:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQ-j-D7us2kG for <>; Wed, 24 Jul 2019 14:16:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F358612029D for <>; Wed, 24 Jul 2019 14:16:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1564003014; bh=qPLwC7UBq1hL8w+r8UV2LQt8HA7m+3I4NpQK2AFa4GQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ets57cUOFG0+0gaJ+UAPkQWA55/NUDKLks4fn6GMV/JuMfGfuii0bn0QF90dSL9gv cTLJQl4j6z/FPo2+sn/NvchsJ206c6VPceHHym811gYM9LdSItoy9pSj8wWDYmhKg/ EcXr7ZGbpaYTWiTNARRK58ClyChkWP037K4HrAI8=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (mrweb002 []) with ESMTPSA (Nemesis) id 0MhlP1-1i4Mqc43xT-00Mvc1 for <>; Wed, 24 Jul 2019 23:16:54 +0200
References: <>
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <>
Message-ID: <>
Date: Wed, 24 Jul 2019 23:16:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ERj7Xt+HHcN2xtZTr4DKiO7YDU7NNCWaOEDAa4Sxk0keSYzT++O P2LgKd9ZoVXJJXCU9G55NQNy7ll3yw8wT1nY86un2dRp5QQjxTnsrqDYgjGmfq+Yi2I4u78 fp9+dIw4pJiKrtS5ydqJawpQc4qyYb/EANsCQY6HvKYeaJ3/juNmJ7+JSQWhzzV37a5dJWF SgezCvRZxY5V5PwQ5GQ1Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:W17iXepMJw0=:VfAFOU6Hklop0SVZiUFPzk SsLqXt1hnHCi+dkgLmc9MXYZFD6QfAbpIgYu/1BESpOA40+O3/AVd5Kw6+Nx2x+mPNaWxeRl0 +91jgIiKrFsPf9+EhIni6C5qjk0EEkkV33GsrYcs4XI3opcAeH0LF/OgSwYjTbtXj3zJCEH/j PzG0lFKTwWzxZum6c74Gx2mBV/QLBS6foi0Q0ATK4QfGKOcdo9udHK55UsJD+cHz3PnHcTn8p Op74QBJnsGUANVK/2jeAJw94hUbNIpg+RqOzOUoZFdz4Pi/Uk9YbTvjO/su1x+PmR++izAynL lE4Fubh+URalB0Qa9xsJROqIPYCK0fmuVFF1PqfYvtrxu0OaDxGULc/JEGaN2Nqq7qbmW6BZ4 TPxdMOfkJPXx+Dh9sRuJue9ofW0RCTLIsV4Zu5lGRNNNjO1PWsYQBi264Hzv3Z7HSvF794en+ FPWlsMKJiP9cGAB9xenHCumMTT7hSCJKndsf5HigbDWOJJKn85hdQ3jAL0iy1hVpk56HvGibt pLCyPca5qPswma2Qc93L8KlqZWwmO7Vpvvi7ZKd50osV/PZpTAasTRiWZ64x7zCS6pMjTEMK4 7GpCZi5QfN8/Mqj7vjw/Hk7kv78xfvRH4v3PJM7soseqmKX4d2X3Lodsx5fITtbU4tCTOM7rQ oC3vG0+ZGLrO5N4M1k/2DfOcIB9AJMEBk4BVr+8dU4CHo9QX8Dx1TjBz5QkpqVI3Hv0prEoxF axKU8SYVoUCAf1u9btWchUMSy8DXCgBXLPJkxqpfkAQa/N4H/uoWzoJnGRvLRpItrnR5pAvVM xbfJPwhqBWSCbwRRdf/ad269wDmhuzOxBT2eI/3HQnW6cB+DjQg4uA78NW+q1MMsHPzUVgDCu jjKp3GbTofzJ3GZGNw9PuuHv/BoXciimDnnZahSNRfxpunVQGeIGRNB88JF153k3dPEU39FVi l3BJfmqMvuIlC1BdUyZb4diiKCgd141WmpIlJQ8UlF+FDJm22EShj7xySllVI9wG8mq+JW4ua smKkXJd934+ISpx6tse/rbfeqbuhT60gdAvEcuGPs28MbNxR6BG4VRfysYc8g2lHrgszx5L2W EYXJ+0+s2/7o/Ooz0vR+JloFfRiHE7VdTZu
Archived-At: <>
Subject: Re: [Cfrg] using hash2curve in a protocol
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 21:17:00 -0000

Hello Dan,

> I want 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.
I fully agree that preparing a constant-time path is the right thing to do.

I have had a short look at RFC 5931 and it looks to me as if this is a
construction explicitly designed for circumventing the EKE and SPEKE
patents. My first impression is that it is way more complex and less
than actually necessary. I think that one should be able to achieve the
objectives with less computations and and less flows?

Are there real-world applications around which are constrained to
use the algorithms of RFC 5931 or are you considering applications
that are newly to be developped?

For new algorithms I'd rather suggest to spend the effort and time for
writing a new RFC, e.g. based on a SPEKE- derivative with subsequent
key confirmation. This way one does not need the inversions and just two
multiplications per peer.

If this approach might be an option for you, I'd be willing to join
forces with writing.