Re: [Cfrg] Dragonfly has advantages

Paul Lambert <> Mon, 06 January 2014 17:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DBE0D1AE12C for <>; Mon, 6 Jan 2014 09:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJYRklZ8Z3pw for <>; Mon, 6 Jan 2014 09:27:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6C81E1AE12A for <>; Mon, 6 Jan 2014 09:27:35 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s06HR0lK009763; Mon, 6 Jan 2014 09:27:27 -0800
Received: from ([]) by with ESMTP id 1h5qbud9r3-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 06 Jan 2014 09:27:26 -0800
Received: from ([]) by ([]) with mapi; Mon, 6 Jan 2014 09:27:26 -0800
From: Paul Lambert <>
To: Feng Hao <>
Date: Mon, 6 Jan 2014 09:27:26 -0800
Thread-Topic: [Cfrg] Dragonfly has advantages
Thread-Index: Ac8LBJGP2QTkqUXvTe+MBn/2fakEmw==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-06_02:2014-01-06, 2014-01-06, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401060101
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 17:27:37 -0000

Hi Feng,

Thank you for the discussion.

>>> -----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.

There seems to be an ongoing disconnect between academic analysis, RFC
publications and real-world applications.

Perhaps clarity in the documentation of use cases, analysis, comparisons
and recommendations is something we can work on within this community.


>>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