# Tag Info

5

The goal of SCRAM is to determine whether the two endpoints share a common secret. SCRAM achieves this by having both parties compare/exchange $\textrm{HMAC}(s,i)$ where $s$ is the secret and $i$ is a counter/nonce. There is more to it than this, but this is the main essence. If $s$ is a high-entropy cryptographic secret, then this is fine: seeing some HMAC ...

5

Dragonfly is resistant to dictionary attacks, meaning that rather than an attacker being able to identify the use of a password in their dictionary with passive computation, they are forced to interact with one of the parties to make guesses. Actually, the goals are a bit more than that; even if you have an active attacker that can either modify the ...

5

Are there any secure password-authenticated key exchange that allows for passwords to be stored as hashes, but does not make the hashes password-equivalent? Yes, they are called augmented or asymmetric password-authenticated key exchanges (aPAKE). They generally build on the scenario that the user knows a password and the server may only store a "...

5

The definition of PAKE just suggests that one or more parties are exchanging keys with knowledge of a shared password that authenticates the exchanged key. There are definitely use-cases of PAKEs that extend beyond, say, a web application authentication process that requires registration. For example, there could exist two or more embedded systems with ...

4

Let's approach the question from this direction. PAKE tries to solve this problem: Alice has a password $PW_{a}$, and Bob has a password $PW_{b}$; consider a protocol where Alice and Bob exchange messages, and generate encryption keys $E_{a}, E_{b}$ where $E_{a} = E_{b}$ if $PW_a = PW_b$ (and unrelated if $PW_a \ne PW_b$); if they're the same, Alice and Bob ...

4

A password authenticated key exchange (PAKE) scheme assumes that the two parties have some shared secret (the password) with too little entropy. They now want to agree on a key and authenticate each other using this password. The trick is to do this in such a way that an attacker cannot brute force the password with recorded data. This ensures the password ...

4

I see three main reasons why PAKEs are not widely used yet: The lack of IETF standards. SRP has limitations discussed in the link @fgrieu posted above. Many PAKE protocols have been designed, but they lack a convincing security proof, or properties some applications may expect. This is being solved as we speak. The CFRG is currently having a selection ...

4

In the Dragonfly protocol on an elliptic curve, the password is mapped to a point $P$, and then both sides exchange (among other things) the values $-mP, -m'P$. If the elliptic curve has a composite order, and in particular, has a small cofactor $h$, then it is easy, given a value $P = xG$ (where $G$ is a generator), to find the value $m \pmod h$, that is, ...

3

The server's data is public That assumption makes the idea of a PAKE undoable. If the attacker has access to all the server's data, here's what he can do: clone the server, place the clone in his lab, and then have his client perform attempted negotiations based on all the passwords in his dictionary. Because the clone works exactly like the original ...

3

but does the use of a modulus or are the exponents literally meant to be exponents alone? Well, in SPAKE2+, all operations are done within some finite group, typically either a prime multiplicative group, or an elliptic curve group. If we decide to use a prime multiplicative group, then yes, addition, subtraction and multiplication are all done implicitly ...

3

Here's the problem with this scheme: suppose $A$ is the honest client, and $B$ is a dishonest server (who doesn't know $s$). Then, $A$ tries to log in, he selects $a$ and transmits $$A = g^{as} \bmod p$$ Then, $B$ just picks a random value $b$, and transmits $$B = g^b \bmod p$$ Then, $A$ will compute a 'shared secret' $$S = B^a \bmod p$$ (which would be ...

3

If you use an augmented PAKE (such as AuCPace or Opaque), the server never gets a copy of the password in the first place. Hence, to update the password, you would reregister with the new password, but the reregistration process wouldn't involve sending the password. If you use a balanced PAKE (such as Spake-2), well, the server does need the password. ...

3

One small issue is that it can be detected if the x-coordinate lives on the base curve or on its twist. There's not a small issue; this allows a passive attacker to halve his dictionary by listening into a single exchange. That is, if $s$ is on the curve, then so will be $s^x$; if $s$ is on the twist, so will be $s^x$. So, what the attacker can do is ...

3

The current TLS 1.3 draft proposal with PSK does not have PAKE properties; in particular, a client can send a single message, get a reply, and then check every entry in his dictionary to search for the PSK used by the server. To do this, the client would send a valid hello, specifying the identity that the client is interested in (and a valid keyshare). ...

2

In the real-world protocol there is no simulator. There is a real-world adversary and it has access to the exact same (random) oracle as the honest parties. The simulator controls the random oracle in the ideal-model simulation only. This is not required by the definition, but is the way that things work. Essentially, the simulator plays the role of the ...

2

No. The whole point of doing a zero knowledge proof (in this case, a non-interactive zero knowledge proof) is that the verifier does not learn any additional information besides the statement that is intended to be proved. The Schnorr protocol allows to prove knowledge of the discrete logarithm without revealing the exponent. On top of that, the Fiat-...

2

And I checked some related works, and most of them only considered the dictionary attack and forward security. Actually, a PAKE has two security goals: That someone cannot recover the password from a number of exchanges (with any greater advantage than being able to test $N$ potential passwords using $N$ active attacks). That someone will not be ...

2

Do PAKE assumes that involved parties already have a shared message? Some do, some don't. In general, there are two flavors of PAKEs; balanced (where both sides do know the password), and augmented (where only one side knows the password; the other side knows enough to recognize it). J-PAKE is a balanced PAKE. in J-PAKE, they used an extension of ...

1

It appears this term is only used in the proof. In this context "dummy password" is to be understood as "some value that syntactically fits the requirements of a regular password including matching the length of the replaced password but is not actually the password to be used in this exchange". The point here is that an adversary cannot distinguish between ...

1

SPHF are a very versatile tool, and they have a large number of applications. Their application to PAKE stems from three main properties: first, they allow for low-interactivity PAKE. Note that this is very desirable, since latency is one of the main source of inefficiency when communicating with a server on the web. To see it, consider a construction with ...

1

Assuming you're actually asking wether there is a difference for TLS in between a (high-entropy) pre-shared key (PSK) and a (low-entropy) pre-shared password, the short answer is: No. The long answer, however is a bit more complicated. By itself the TLS-PSK ciphersuites don't differentiate between different degrees of entropy. However there are a few TLS-...

Only top voted, non community-wiki answers of a minimum length are eligible