Re: [Cfrg] Suggestion for open competition on PAKE -> Was Re: Dragonfly has advantages

Trevor Perrin <> Sat, 04 January 2014 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 428F81AE082 for <>; Sat, 4 Jan 2014 09:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QUHbYjuTXrRM for <>; Sat, 4 Jan 2014 09:18:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 819C31AE010 for <>; Sat, 4 Jan 2014 09:18:52 -0800 (PST)
Received: by with SMTP id j9so1446687wiv.2 for <>; Sat, 04 Jan 2014 09:18:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BqZQzWONFHmnPC3iyGK78Qo6n8ZNpr9EHeIgAuM+sT4=; b=WU0MgDsWtpx0WfVrZ/FGxkLbEPjv1/ueqaagwKZNqfJHrCdTD7wy/JNYW5Samllrs3 J0ux0xEEKXLPh2N5UG+ITyAvCeTu7RBas8eWwSaIA5l8VxSKVQA+Fw2mc2oiwsY2TcnF /oovga1l3yhjomeFkxiFmdTq8NOLdqU5dMI8WdNo+a1+NOJh71pjM8/uYIn61hdihF+g Lhpep5eM9hgQLTCddfNRI9Z8d5cfeAKuCZbm3XhKltlaNnFE2lIyntt7UxzexwLqQ/t5 TbS8UitZs0nhiLfs620x17Y3OFx8jFoGTAnmJp5MTq5ku5+5kE5PdJxVC0KBttS5Cz1u H++Q==
X-Gm-Message-State: ALoCoQkxZCB2kiD1XfJ+zPOmeBTvO3+L7gvNjl0GxLkGIfVJIK6kemCVIepVuXVnQQRhOix8ZsWc
MIME-Version: 1.0
X-Received: by with SMTP id fq8mr6140657wic.26.1388855924338; Sat, 04 Jan 2014 09:18:44 -0800 (PST)
Received: by with HTTP; Sat, 4 Jan 2014 09:18:44 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Sat, 4 Jan 2014 09:18:44 -0800
Message-ID: <>
From: Trevor Perrin <>
To: Feng Hao <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: David McGrew <>, "" <>
Subject: Re: [Cfrg] Suggestion for open competition on PAKE -> Was Re: 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: Sat, 04 Jan 2014 17:18:54 -0000

On Sat, Jan 4, 2014 at 7:23 AM, Feng Hao <> wrote:
> In summary, if the password element derivation in Dragonfly can be done
> securely and efficiently, that would be a good contribution in my view.
> That would even resolve an issue that SPEKE can't. The way that SPEKE
> works is by requiring the use of a safe prime, but then for 1024-bit p,
> the exponent will be 1023 bits - one modular exponentiation will be
> equivalent to about 6 times of the exponentiation with a 160-bit exponent.

Hi Feng,

Minor comments:  I don't agree that Dragonfly could "resolve an issue
that SPEKE can't".

It's true that SPEKE is generally described in terms of safe primes to
avoid the problems Dragonfly is running into.

But any password element derivation that works for Dragonfly would of
course work for SPEKE.

> (Some people compare PAKEs by merely counting the number of modular
> exponentiations, but they should also look at if the protocol readily
> accommodates short exponents. The length of the exponent has a direct
> impact on the cost of exponentiation.)

Another important issue, particularly for EC protocols, is to
distinguish operations with a fixed base (or fixed point) from
operations with a random base / point.

The fixed operations can be optimized to be several times faster
(perhaps ~4x is a rule of thumb I've heard).