Subject: [Cfrg] Additional questions to consider for the PAKE Selection Process

From: "Hao, Feng" <[email-masked]>
Date: Fri, 14 Jun 2019 11:06:56 +0000

Dear CFRG,

I would like to suggest the following additional questions to consider for the PAKE selection process.

  *   A PAKE scheme should define how the explicit key confirmation is performed and clearly state whether this procedure is optional or mandatory.
  *   The authors should state if the two communicating parties can initiate the key exchange process at the same time, or it must always be the case that only one party can initiate the process.
  *   (Related to above) The authors should clearly state the “round efficiency” of the PAKE protocol. In a standard two/multi-party secure computation setting, the “round” is defined as a step in which all parties can complete operations at the same time without depending on each other. In practice, a 2-round protocol could be implemented as 2 flows or 3 flows depending on the application context, but that’s more the implementation detail.
  *   If a PAKE scheme relies on the assumption of a trusted setup--more specifically, the discrete logarithm relationship between the two group elements in the system setup MUST be unknown--in anticipation of the worst but not impossible scenario, the authors should clearly state the security implications when the discrete logarithm relationship becomes known, and the subsequent mitigation measures.

Any comments are most welcome.

Cheers,
Feng

---

From: "Björn Haase" <[email-masked]>
Date: Tue, 18 Jun 2019 19:09:33 +0200

Dear CFRG,

I would like to come up with the following suggestions

for structuring the PAKE selection process.

When re-reading earlier discussions on the CFRG mailing

list, the topic of PAKE protocols seems to have

led to controversial arguments.

One reason might be that we don't have a common

understanding of the target use-cases and application

requirements.

I had a number of off-the-list discussions with several

people, including those who have nominated candidate

algorithms and wrote RFC8125.

What I have taken with me from these off-the-list

discussions is, that there seem to be several

use-cases with different and largely contradicting

requirements.

In the off-the-list discussions I did identify the

following two main use-cases described below which

I have and numbered U1 and U2.

In the discussion process we might come up with some

other use cases, However I expect that likely we will have

also very similar applications in mind, so that we might

be having 3 or 4 different application settings.

I would like to suggest that in the process of the

discussion we all contribute to a growing common list of use

cases and applications, such that we could discuss the

respective advantages and drawbacks of nominated

algorithms for the different scenarios.

As additional question for the PAKE selection process

I would thus like to add the question in addition to the list in

RFC 8125:

"A nomination SHOULD specify for which use-cases the protocol is recommended."

####################################################

U1) PAKE as a more-secure replacement for a

PSK on a machine-2-machine interface.

####################################################

In some applications machine to machine interfaces

need a first initial trusted setup, say for

connecting a device to a WIFI router.

The initial setup might involve typing a "join code"

using a HMI unit with strongly reduced capabilities,

having maybe only three buttons. The key benefit

of the PAKE in this setting is, that a high-entropy

"join key" could be replaced by a lower-entropy

"join password" while improving security.

Similar needs show up for initial security

configuration on a small sensor node in an industrial

plant or for a join operation of a small sensor node

with some cloud server application or wireless sensor

node network.

#### U1: Derived requirements

- No need for individual human user names and accounts.

In U1, PAKE is used for somethint that should actually

be considered a machine-to-machine interface.

Specifically for U1 there is no need for several

accounts with possibly varying authorization rights.

For U1 the PAKE does not need to transfer a user name.

- Tight performance requirements.

The second aspect here is that performance

requirements might be extremely tight.

For instance today the join operation for a wireless

HART(c) industrial sensor node network is based on

symmetric primitives only for performance reasons.

The small microcontrollers had been assessed to be

incapable of running asymmetric crypto.

Note that for similar reasons for implementations on

tiny microcontrollers such as a Arm Cortex-M0 or 80C51,

the Bluetooth-Low-energy Standard in its version

4.0 had dropped any asymmetric crypto which resulted

in severe security issues.

####################################################

U2) PAKE for securely accessing a remote HMI

interface server (e.g. a web server) without

configured WEB-PKI certificates.

####################################################

More and more devices, such as home-automation

surveillance/security cameras combine the needs

for security/privacy with the customer desire to access

the HMI interface by remote handheld units with

using conventional off-the-shelf tools, such as a

web-browser.

As-shipped, these IoT devices will not come with a vaild

WEB-certificate allowing for establishing a conventional

TLS link providing MTM protection.

Similar use-cases show up in industrial automation

settings where devices such as sensors increasingly

come with IP-protocol or even wireless direct internet

connectivity, where already the initial configuration

login is performed over a vulnerable wireless link.

This type of server device might be physically accessible

for adversaries. (e.g. a surveillance camera at the

house gate) and often might not have ressources for

calculating state-of-the-art password hashes.

The HMI units would be tablets/PC/Smartphones with

comparably powerful computational capabilities.

There might be more than handheld HMI unit such that

individual configuration of several HMI units is

not desired.

Often there might be several server devices (e.g.

three cameras at one house) which commonly are

configured to the same user passwords.

#### U2: Derived requirements

- The login is of conventional "username/password" type

with possibly several users having different

authorizations.

- Because of physical accessability the user-login

credentials should best be protected in secure elements.

At least use strong password hashes should be highly

desirable.

- A convenient method for synchronizing user credentials

between a set of servers is desirable, even if a centralized

management infrastructure might not be available.

---

From: "Björn Haase" <[email-masked]>
Date: Tue, 18 Jun 2019 20:40:12 +0200

Hello to all, I hope that via this list I might be able also to reach the contributors of the

draft-irtf-cfrg-hash-to-curve draft at github

https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/blob/master/draft-irtf-cfrg-hash-to-curve.md

over this list.

Regarding the Elligator 2 map, the algorithm shown in the  github version of the draft is actually slower than necessary. It requires two exponentiations (for one inverse and one square root).

Some time ago Mike Hamburg did point me to a solution on how to implement this with one single exponentiation. The algorithm is found also somewhere hidden within the Ed25519 paper of Bernstein, Duif, Lange, Schwabe and Yang. Still Benoît and me did consider it helpful to write down the faster algorithm explicitly in our last paper, because we thought that there might be others that missed this optimization opportunity :-).

You'll find the explicit write-down in section 8.2 on page 33 of

https://tches.iacr.org/index.php/TCHES/article/view/7384

Yours,

Björn

---

From: "Björn Haase" <[email-masked]>
Date: Tue, 18 Jun 2019 22:03:15 +0200

This is a re-post: Eric Crocket informed me that my posts today did not get through.

.

 
 
https://tches.iacr.org/index.php/TCHES/article/view/7384[https://tches.iacr.org/index.php/TCHES/article/view/7384]
 
Yours,
 
Björn

---

From: "Björn Haase" <[email-masked]>
Date: Tue, 18 Jun 2019 22:05:13 +0200

Dear CFRG,

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 27 Jun 2019 08:43:21 -0700

Thanks for the pointer, Björn! I filed [1] to track this issue.

Best,
Chris

[1] https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/133

On Tue, Jun 18, 2019, at 11:40 AM, "Björn Haase" wrote:
> Regarding the Elligator 2 map, the algorithm shown in the github 
> version of the draft is actually slower than necessary. It requires two 
> exponentiations (for one inverse and one square root).
> Some time ago Mike Hamburg did point me to a solution on how to 
> implement this with one single exponentiation. The algorithm is found 
> also somewhere hidden within the Ed25519 paper of Bernstein, Duif, 
> Lange, Schwabe and Yang. Still Benoît and me did consider it helpful to 
> write down the faster algorithm explicitly in our last paper, because 
> we thought that there might be others that missed this optimization 
> opportunity :-).
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 27 Jun 2019 09:01:44 -0700

On Tue, Jun 18, 2019 at 11:40 AM "Björn Haase" <[email-masked]>
wrote:

> Regarding the Elligator 2 map, the algorithm shown in the  github version
> of the draft is actually slower than necessary. It requires two
> Some time ago Mike Hamburg did point me to a solution on how to implement
> this with one single exponentiation. The algorithm is found also somewhere
> hidden within the Ed25519 paper of Bernstein, Duif, Lange, Schwabe and
> Yang. Still Benoît and me did consider it helpful to write down the faster
> algorithm explicitly in our last paper, because we thought that there might
> be others that missed this optimization opportunity :-).
>

(I think I wrote out something similar in
https://www.imperialviolet.org/2013/12/25/elligator.html . I'm not very
good at these things so the steps are smaller and more numerous, but that
might be helpful for some.)