Questions tagged [pake]

Password-Authenticated Key Exchanges (PAKE) are authenticated key exchange protocols where the long term secret is a (low entropy) password. I.e., it's a 2-party protocol with at least one party using a password to authenticate themselves to the other party. A PAKE guarantees, that the parties establish a shared session key if and only if authentication was successful. Due to the low entropy of passwords, it's crucial to prevent offline dictionary attacks.

Password-Authenticated Key Exchanges (PAKE) are a special class of authenticated key exchange protocols. In general, an authenticated key-exchange protocol allows two parties to establish a secret shared session key, while at the same time authenticating themselves to one-another. In a PAKE, the authentication factor is a password, i.e. a low entropy long-term secret. The authentication can be mutual, where each party authenticates themselves to the other, or one-sided, where only one party authenticates themselves to the other.

A PAKE should guarantee, that the parties establish a shared session key if and only if the authentication was successful and this secret key should be remain computationally hidden from any outside observer, even if this observer can engage in other protocol executions with those parties. While there is a multitude of different formal definitions of security, most are derived from the classic Bellare-Rogaway model for authenticated key-exchange.

One of the important fact to notice about PAKE is that due to the low entropy of passwords, dictionary attacks are always feasible. For this reason it is crucial in the protocol design to prevent offline dictionary attacks. An offline dictionary attack is possible, whenever an outside observer can use one or more protocol transcripts to verify a guess for the password. Since passwords have low entropy, this would render the PAKE broken. In contrast, online dictionary attacks cannot be prevented. In an online dictionary attack,an attacker has to run a new protocol execution for each guess they are trying to verify. This allows to mitigate the attack through approaches such as rate limiting.

42 questions
9
votes
1 answer

Why would the use of Curve25519 in Dragonfly leak information?

An answer explaining Dragonfly, a form of key exchange used in WPA3, has an interesting footnote: One final note: reviewing the Firefly RFC, I see that it would (as written) leak some information if you run in on an elliptic curve that doesn't have…
forest
  • 15,626
  • 2
  • 49
  • 103
6
votes
1 answer

How does Dragonfly key exchange work, in non-white-paper terms?

I'm trying to understand WPA3, whose Simultaneous Authentication of Equals is supposedly similar to Dragonfly Key Exchange. Dragonfly is resistant to dictionary attacks, meaning that rather than an attacker being able to identify the use of a…
Sarkreth
  • 203
  • 2
  • 6
6
votes
1 answer

Provably Secure Password Authenticated Key Exchange Based on RLWE for the Post-QuantumWorld

In this paper (Provably Secure Password Authenticated Key Exchange Based on RLWE for the Post-Quantum World), author describe password authenticated key exchange scheme on page 9 and 10 (see Fig. 1 on page number 10). I have following doubts in…
vivek
  • 217
  • 3
  • 13
5
votes
2 answers

What's going on with the complicated implementations for map_to_curve in draft-irtf-cfrg-hash-to-curve?

I've been looking into implementing cPace, and I saw that two cipher suites defined for it refered to draft-irtf-cfrg-hash-to-curve for its protocol definition. Part of cPace requires mapping a string hash to a point on the elliptic curve, so it…
LRFLEW
  • 153
  • 3
5
votes
0 answers

Can "OPAQUE-over-TLS" authentication be optimized?

So while discussing the issues of password-hashing off-loading in our chat I noticed that it's easy to extend OPAQUE (CFRG draft) to essentially be a better standard password based authentication when executed over TLS. Namely one could simply…
SEJPM
  • 46,697
  • 9
  • 103
  • 214
5
votes
1 answer

Designing of Password Authenticated Key Exchange (PAKE) Schemes?

I am started working in post quantum cryptography(lattice based cryptography) specifically in Password Authenticated Key Exchange (PAKE). I come across many PAKE key exchange scheme (like this one) that do not take in consideration the registration…
vivek
  • 217
  • 3
  • 13
5
votes
1 answer

Can the TLS 1.3 PSK-DHE handshake be turned into a PAKE?

Recently, we had the question whether there's a PAKE that uses more standard, higher-level primitives than what SRP offers. Now this made me think and ask myself: TLS does have a PSK mode, can't we leverage that? This shall be the theme of this…
SEJPM
  • 46,697
  • 9
  • 103
  • 214
4
votes
2 answers

Have any PAKE extensions been added to TLS 1.3?

In TLS 1.2, there was TLS-SRP (RFC 5054,) which provided a password-authenticated key exchange (PAKE) protocol for use with TLS. However, it apparently relied on handshake messages that have been removed from TLS 1.3 and, thus, is not applicable to…
reirab
  • 175
  • 10
4
votes
1 answer

Why are PAKE protocols not widely used?

While there are plenty of PAKE protocols, especially those augmented ones which are practical in C/S model, actually they seem to be not widely used. Even TLS-Standardized SRP, the most popular one among them, I just know it's used in apple's…
weir007
  • 41
  • 2
4
votes
1 answer

An efficient SPEKE protocol with curve25519

SPEKE is a very simple and elegant PAKE protocol. I think one of the reasons why PACE was invented and is now the ICAO protocol is that SPEKE was patented. Fortunately, the SPEKE patent expired in March 2017 and therefore we can now freely use it. …
user27950
4
votes
2 answers

On the security definition of password-authenticated key exchange

I found in all PAKE papers, the security is defined as something like this: Let $Succ(A)$ be the probability that an attacker $A$ successfully distinguished the session key from a random string. Then the advantage of $A$ is $Adv(A) = 2 \times…
Jan Leo
  • 925
  • 6
  • 14
4
votes
1 answer

"Oblivious" Argon2id? (or comparable KDF/KSF)?

Is it possible for a client to send a blinded password to a server, so that the server does key derivation+stretching on that blinded value, but the key can then be unblinded by the client? Clarifications I'm using "blinded" the way it is used in an…
mtraceur
  • 309
  • 1
  • 7
3
votes
1 answer

Is the following PAKE protocol UC secure?

Consider the following (simplification of a) PAKE protocol: Alice and Bob start with a pre-agreed password pw. To establish a new session key $k$, first Alice samples a random nonce $r$ and sends it to Bob. Bob samples a nonce $r'$ and sends it to…
Jabari
  • 33
  • 3
3
votes
2 answers

Why does the PAKE ideal functionallity allow the keys to be the same when the passwords differ?

My intuition for the security a symmetric PAKE is supposed to provide comes from the example of a login page. Both the user and the server know the password (assuming unhashed passwords), and the purpose of the protocol is to authenticate both the…
qbt937
  • 258
  • 1
  • 8
3
votes
1 answer

Do all PAKE assume that all parties already have a password?

I was looking for a means to perform a key exchange without relying on a PKI. I discovered Password Authenticated Key Exchange (PAKE) and after reading J-PAKE; I have the following questions: Do PAKE assumes that involved parties already have a…
vxek
  • 551
  • 3
  • 10
1
2 3