Re: [Cfrg] I-D Action: draft-irtf-cfrg-hash-to-curve-04.txt

"Björn Haase" <> Tue, 16 July 2019 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A4E9120168 for <>; Tue, 16 Jul 2019 14:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 jMvuOr1FwTnc for <>; Tue, 16 Jul 2019 14:39:59 -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 634B61203FB for <>; Tue, 16 Jul 2019 14:39:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1563313195; bh=D0eNPJYXxMv9Y/+EI1/9WfnuUIHB6K3Ox2RYHQ/LSvw=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=oTd+vdaIvlfxxdpqx1Zktuo/nXPn4cYf2tfZcMh983jkTqj77UYv5buykT6iCDraR ueMWYW4zlX4pyoPBUIng/a/EWG0X0v9xDf8quqrScdnoTrAjSXJaJD45P0VEZ7MpyP ngynOiermMvYN/ROH8kxIS2S976OubhyVIvzf8OA=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (3c-app-webde-bap35.server.lan []) (via HTTP); Tue, 16 Jul 2019 23:39:55 +0200
MIME-Version: 1.0
Message-ID: <trinity-cfd033b0-20a0-4aef-a41b-a1088aa3b2bf-1563313195349@3c-app-webde-bap35>
From: =?UTF-8?Q?=22Bj=C3=B6rn_Haase=22?= <>
To: "Riad S. Wahby" <>
Content-Type: text/plain; charset=UTF-8
Date: Tue, 16 Jul 2019 23:39:55 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <>
References: <> <> <> <> <> <>
Content-Transfer-Encoding: quoted-printable
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:niL1qAhaPv0Bf/7VFNimK+v2Es32msFWAB5I23Mnk2k+tFjgeTvA2PmiZvkvYiss35qS0 Rzw1zk9mxrAsdTea7DdtSOr36gyO4Sb9K1EYfKkX55MS3UKKgJlSjRzqB10zRb4OnXoBaOmrnbN6 B/twFa43ZftxbJ2VNltN1YKLI5ZIhZSOp9xhwyLrQwziBvwMOXixy71PjeT1JyrFT3/jjsbWb+3z mN0DMgn+QSWC1359Zh0IKNBQy3HNyOdVE15fgihy2HrFGFLiX+nwd6z50J8mmT4MxZlIm0h6iQ4+ IQ=
X-UI-Out-Filterresults: notjunk:1;V03:K0:06TZ/LiYwqk=:Rzjin3ZwjEGMHDtLDs+uPf 9oCwBVUX94CsYaRp4O91gm5cVHtt6bZ97BvEGIl1SxqEntogeWZc6MfBv7OmKKDtjfxeWcwqd 6d54AvhGMEdD4F6aMSvInfWu87klpKaKcxT3VmM9H9pq8syrSG9K27AiUF7h22Dkkg5sgkiOm rznXreEPHg6R6QCZNgbraFTyYjxROpq1VLWQ4a/w6LdsLzWYshJ05pgZZ0T6uKiGIst+DDJbn kwQbX07LG2s0nYYY7zozReW4AtOYmAoAOL1YX1xR5r9XJ22UvQnuGWsmQZhXOf7gy9W3oJqDB TN2T0t2gX9+o6shvDr/FlovwoHhQxbpi3hYTNrM0breg5Vk9RI90nsve5hOFqm/HCyEPEdWPE ZZllWk3ZlkY+lMuu3pBqXVfCQT5s8WbkpL4vcOoKTgf4xCvtyAPQGRkXs9AHdt3iRfJ0QWHLZ 2jpaLpHuPOCXfD0qDeegRqXjyN78ZNTcIJQv2osApueXEOaap/XpaRw50TkKUCW2FckTFEA81 KN9yUNMOS07cO3BSAG7F1bHZHk7fpphp/+s7E803lbAUc29zBcw2bIHwO2FXjcXoIQJ7r83Lw OJm/ty+NH0aUjKJtK2OqrkWb75fXh/JTsQkOxjw0V9ijMnrMRPIZYtvA==
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hash-to-curve-04.txt
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: Tue, 16 Jul 2019 21:40:04 -0000

Dear Riad,

>....if we lived in a universe without IPR concerns, my opinion would be
>that only Simplified SWU should be included. 
Yes. I agree with you here.

>The reason is, including
>any given algorithm is (at least tacitly) endorsing its use, and as
>far as I can see there is no *technical* justification for endorsing
>SWU over Simplified SWU.

We'll have to struggle with the following situation: If we have too many options, we might face an incompatibility nightmare and complexity. And all complexity is bad for security because at least one of the options might have an exploitable implementation pitfall.

On the other hand dealing with licensing issues or even disputes at courts is extremely painful. Also a mere IPR conflict risk might motivate people use the second-best option security-wise or even scare away people from a helpful and more secure technology.

In my opinion dealing with this type of topic is something specific for an organization such as IETF or CFRG, in contrast to pure research work.

I have made quite some effort on analysis of possible IPR issues for hash2curve. Concluding my analysis today gives the following result:

- I believe Icart's mapping for curves with p mod 3 = 1 is covered by the morpho patent. For a product of my employer, I'd would not recommend using this approach without purchasing a license.
- I believe that simplified SWU in the form of the current draft is not covered by the claims in the patents that I have read so far. I would recommend using simplified SWU in products of my employer, however only after having arranged for an assessment by an experienced patent attorney and an assessment of *all* national applications or patents. Sometimes the claims differ significantly and there might be the risk of divisional applications with new claims in some countries, once the standard comes out.
- I believe that plain SWU is not covered by patents. For the plain SWU algorithm, I would recommend my employer to use the algorithm without the need of further analysis.

Summing up the only IPR issue in the current draft is Icart's mapping for P384. I have filed an official IPR notice for this aspect.

I believe that SWU and simplified SWU are not covered and I did not file an official IPR notice. Still when working on the draft, I'd like to suggest that the Icart and Icart/Coron patents regarding optimizations for plain SWU should carefully be kept in mind.

I further believe that apart of the two patents from Icart and the one from Icart/Coron no further patents might be around.

Yours Björn,

P.S.: Sorry for bothering you with these painful topics. Still I believe that getting a clear common picture on the IPR situation for hash2curve will be important pre-requisite for establishment of consensus regarding protocols for OPRF and PAKE.