Re: [Cfrg] dragonfly, was: Re: Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

Björn Haase <> Wed, 27 March 2019 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 437911203CC for <>; Wed, 27 Mar 2019 10:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 i4z0yUV4f3J4 for <>; Wed, 27 Mar 2019 10:57:16 -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 438C91203B1 for <>; Wed, 27 Mar 2019 10:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1553709212; bh=rbfkRIsyLufiXxAvDeaO+UwY+kq4k6EQn886ygFFdLc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=I9X5d7dpar5YfbQB2ukyeQ5grAtNBa1KnCW5SDSVLhmtSuv8XFw/R9F9ofCEzh22q I/yyQt9elHDiwOSggsKRxPIuv7Ocjjc3YOWBVoVHXP4UnsQP5sKyYGeGPHw6tn0RW9 kQIv2coWpQ9sItJ0G4bxRJhRpQ5/Dv0VRiYq1OGg=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (mrweb103 []) with ESMTPSA (Nemesis) id 0LgHPM-1gfJyZ2zqu-00ne8O for <>; Wed, 27 Mar 2019 18:53:32 +0100
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <>
Message-ID: <>
Date: Wed, 27 Mar 2019 18:53:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------D07C9A03EF76EE4CB1A72675"
X-Provags-ID: V03:K1:qqYtHnVQOROsGz0Hd93JZ2nnwQfPIRv9A38zXpvsTh4xgGgqxxk s8K9RlCTgZT58+6m7RYGTsHsY//C2ePQiynUlZsP1ZhEAdE57LE3f5su04UE6SBat7I0DDR dNImapjh54Aus6lFgTfuQAJoIQF3sWbwoXX8Mc5b+YI4bT2zu91WAididEG+bGvgmESJmFl vC1QlOMG6k8gipp0KOlFg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:4psjOsXuW0o=:dkN7Pv8GKa1+py3qieFsGR cLt3rbjndni0efiUKO9fy/+Wig8ieTeC3YnQA9Qbf/nayHNdOzV9Tk8dFswvjdWo7+aMoXi+G X4OVRPqDE7qut0rzTtkwJzAXQLImA3jMJxYA1cJpwx8HB/8wkARDIYR+0edHre/uV0EHAfAAs SZFW+fmAgkLDWLfd0XmRgwQ9m1ArNfVNLAm/ewiBsJ03NWNAFcwBgoVs8IM2PNrBD8uGU3KpJ qj0pda+hfdza3dBs/N7VN41XfbURw1Y8hAzuakg0CsPcQGNWaWy2rd2VdJhoo0w3LKdTCsP7E AoVy/1JrQikgm53H7GJ49iLG5O/9J3J5lwbvt7TmraUn6QRM6rXRD7Tkf6tAXE75VuYqaeSjC Mufy11GDsBB9r6wjV5VVIE9qhhJCKgk2iQD20+70R6lLgH8k8uAXY/pyHOdmyA+ie4HlgSGYh j5inhN349gXu1RqYNunQGU00mFe4qw/b9hSQF2jq+twvEnD1YSu3ZzhcBYs7RjYTl5AArXq7a wGHN9jSEn8LwhBgKfEqlzzTx+sRyVTzy4hskK25RI0fTwU/e6x5wmDvYZwmq0ZoJUz6bfbToR LaBEAlTCWQ8qV2x5eCRiHzvp9Ywhs+uTLKBE9QktxvN8cDu1bUtKXJfrV+zYvySkocojFTcuI 9QHh0ghPOHDEB+atnE0wx0UVT+TwSlJ0mbJZfjXIFfqgHbbYLLyVcYX80LcVVbE9y0DSrUqvr Adg+Uia9/2aEu4Am0RmCgZQyrp95IE7OlXu0BX5JzTvqgA1/zzqKEp6YCQbhc7BlhOjKBflqW Wci/QXuPceh0X8Z7cLIp7Q5mBcj7Xk2Gex+A2ApQA1lzK56CNtl1aTP5U5EgSIOQlXChKTUSo ZsErIBSk1zxv3VfBN0pgvxfQ0Qa3RvACk/9VOqo33D2aYsWkGp29AMPwEshrB8eRqYyWJMsLk ArupAV19F+g==
Archived-At: <>
Subject: Re: [Cfrg] dragonfly, was: Re: Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts
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, 27 Mar 2019 17:57:21 -0000

As a cryptographer working on PAKE, I am somewhat astonished to learn
that IETF might seriously considering to consider a construction like
dragonfly for standardization.

There are several defiencies in Dragonfly in my assessment.

1.) The fact that a "Hunting and Pecking" method is prescribed for
generating secret common group element is -- in my opinion -- the major
security and efficiency problem.

Note that its not a problem to deal with in a security proof because
this is a pure implementation pitfall issue because it makes
implementers very tempted to choose insecure "speedups". Saying this,
after having experience with rolling out security solutions in teams
without crypto and security experience, I am convinced that this major
implementation vulnerabilities *would* be showing up in real-world
settings. Specifically on resource-constrained targets.

Seeing that SPEKE and EKE patents have expired recently and seeing that
decent and carefully analyzed alternatives such as the SPAKE
constructions PACE and it's derivatives or TBPEKE (the balanced version
of VTBPEKE) are available I personally am astonished to see that
nowadays somebody might actually consider to newly standardize any
protocol requiring "Hunting and Pecking"!

2.) Another point is the requirement completely ruling out
state-of-the-art high-speed Edwards curves (co factor must be 1 for
dragonfly). In my opinion this again comes with the risk of adding
implementation pitfalls. Implementations focusing on DJB's Curve25519 or
Mike Hamburg's 448 would have to add and maintain/patch
short-weierstrass algorithm families.

In my opinion there are by far better and more inter-operable choices
available than dragonfly for balanced PAKE, especially SPAKE and
SPEKE-derivates (such as PACE and CPace) which are more secure in
real-world settings (considering the risk of implementation pitfalls and
non-constant run-times).

Were the points I mentioned above regarding problems with dragonfly
considered beforehand on this list? I would believe that these points
are so obvious that getting consensus on these aspects among
implemention-oriented cryptographers would be easy to establish.



Am 27.03.2019 um 17:37 schrieb Tony Arcieri:
> There is, if nothing else, some confusion around the IETF's
> relationship to Dragonfly, both within the WiFi Alliance and by tech
> journalists. Some examples:
>     Also note individual submission:
>     <>EMU
>     and Security Area review incorporated, IETF Last Call pending..
>     Related draft (will be RFC 7664), see
>     WPA3 Personal authentication is a process called a simultaneous
>     authentication of equals (SAE), which comes from the *IETF
>     Dragonfly* <> key exchange.
>     Robinson says that with SAE, the authentication requires
>     interaction, and only after authentication will the keys be
>     generated. This makes attacks that depend on cloud-based server
>     farms and automated key attempts unavailable to attackers.
>     "SAE uses a Dragonfly handshake defined in the Internet
>     Engineering Task Force (IETF) RFC 7664 specification and applies
>     it to a WiFi network for password-based authentication," Robinson
>     explained. "The Wi-Fi Alliance WPA3 specification defines
>     additional requirements for devices operating in SAE modes."
> From what I've observed, the IETF's name seems to end up attached to
> Dragonfly quite a bit. Curiously in these quotes, the CFRG and IRTF
> aren't mentioned at all. Perhaps this speaks to a more general problem
> around public perception of RGs and informational RFCs (or lack
> thereof), but when I read quotes like this, they sound to me like many
> people's perception is that Dragonfly is a standards-track IETF RFC.
> Issues like educating the tech press and trade associations on the
> difference between the IETF and IRTF and the difference between
> standards-track and informational RFCs aside, I think the main thing
> the IETF could do address these concerns is actually create a WG
> dedicated to producing a standards-track PAKE for similar use cases.
> PAKEs are certainly a hot topic these days, both on the CFRG (see
> OPAQUE thread this morning) and in cryptography in general.
> --
> Tony Arcieri
> _______________________________________________
> Cfrg mailing list