Re: [Cfrg] Dragonfly has advantages

Feng Hao <> Mon, 06 January 2014 13:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11FEB1ADBD4 for <>; Mon, 6 Jan 2014 05:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k0Kz51mKlnMk for <>; Mon, 6 Jan 2014 05:01:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC73A1ADBD1 for <>; Mon, 6 Jan 2014 05:01:42 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.63) (envelope-from <>) id 1W09oD-0001xE-AX; Mon, 06 Jan 2014 13:01:33 +0000
Received: from ([fe80::c039:e17:9d60:9f3]) by ([fe80::517e:5471:8227:7937%10]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 13:01:32 +0000
From: Feng Hao <>
To: Paul Lambert <>
Thread-Topic: [Cfrg] Dragonfly has advantages
Thread-Index: AQHPCnLdZWZqHtlLtUCc2iothWRdhpp3qe6A
Date: Mon, 6 Jan 2014 13:01:32 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Cfrg] Dragonfly has advantages
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jan 2014 13:01:45 -0000

Hi Paul,

On 06/01/2014 00:04, "Paul Lambert" <> wrote:

>> -----Original Message-----
>> From: Feng Hao []
>Hi Feng,
>> >I agree that it has more complexity and message exchanges that other
>> >approaches.  These other protocols have NOT been viable to ship in the
>> >products I build.
>> Have you looked at J-PAKE? It's a balanced PAKE, same as Dragonfly.
>No, not in too much detail, yet ... looks of similar complexity.

Well, if you look into the protocol and the proofs, you may realize that
J-PAKE is designed for "simplicity" rather than "complexity".

It is my belief that keeping things simple (which should include the
protocol specification, security proofs and implementation) should be the
the most important consideration in the design of security protocols. Some
people may not realize it, but the hardest task in designing a security
protocol is actually to "keep it as simple as possible".

>Interesting, thanks for the reference.
>I assume this is a related better spec for this forum:

Yes. Also note that the protocol has remained unchanged from its initial
publication in 2008.

>Seems like the identical problem space as Dragonfly, but a later attempt.
>Less critical review so far ...

Not sure if it's a later attempt, but J-PAKE was first published in 2008.
It may not be obvious to some, but the protocol has actually been
extensively analyzed by researchers in the security community and the
industry in the past 5 years. We patiently waited for 5 years to give the
public ample time to scrutinise the protocol and the proofs, and so far no
attacks has been found.

But as always, I welcome most critical reviews from people on this list.
Feel free to post your comments on the lightbluetouchpaper blog, which is
open to everyone to comment.

>Note - a nearly identical version of Dragonfly	 is baked into mesh
>networking ... so I still want to see Dragonfly progress to ensure the
>side-channel implementation details and the like are clarified to fully
>address the comments.

Of course. I think a prototype implementation of Dragonfly (in c or Java
etc) would help clarify a lot of things.

>> In the update of "2013-12-30", you can find a prototype implementation
>> of J-PAKE using the elliptic curve group setting.
>> Cheers,
>> Feng