Using D-SPHF we can “explain” the 2KOY proposed by Katz et al. [127]; similar to Gennaro and Lindell [101] who “explained” the original KOY protocol from Katz et al. [128]. We define encryption schemes and D-SPHF used in 2KOY, highlight changes to our framework and discuss implications of this on the security of 2KOY.
The crs contains a public key pk for Cramer-Shoup encryption as well as a public key g3 for El-Gamal encryption. Since 2KOY uses El-Gamal encryptions on the server
side, we have to use a combination of Cramer-Shoup and ElGamal based D-SPHF here. Instead of using Cramer-Shoup encryptions and D-SPHF, the client computes projection keys for an ElGamal D-SPHF.
Likewise, the servers compute projection keys for a Cramer-Shoup distributed GL- D-SPHF and El-Gamal encryptions of their password shares.2 Recall that Gennaro and
Lindell [101] formally introduced the first use of SPHF in the PAKE setting, denoted by GL-SPHF here. To describe GL-SPHF on labelled Cramer-Shoup ciphertexts in the framework from [29] it is sufficient to define the following variables:
Γ(C) = g1 g2 h c 1 1 1 dξ T ∈ G4×2
λ= r ∈ Zp and Θaux(C) = (u1, u2, e/m, v) ∈ G1×4
2Note that an additional signature on the session transcript in round three ensures “non-malleability”
4 Two-Server PAKE from Distributed SPHF 147
Client C Server S1
Input: crs, pwd, S1, S2 Input: crs, s1, C, S2, ˆC2
(vk, sk) ← Gen, ℓ = (C, vk) (kh1, kh′1) ← KGenHCS(Laux)
C1,0← EncCSpk(ℓ, pwd; r1) C2,0← EncCSpk(ℓ, pwd; r2) C1,0, C2,0, vk −−−−−−−−→ (kp1, kp′1) ← KGenPCS(kh1, kh′1, C1,0) (kh1,0, kh2,0) $ ← KGenHEG(Laux) (kp1,0, kp2,0) ← KGenPEG(kh1,0, kh2,0, Laux) C1, kp1, kp′1 ←−−−−−−−− C1← EncEGg3(g s1 1; r1) C2, kp2, kp′2 ←−−−−−−−− σ ← Sign(trans, kp1, kp2) h0,1← PHashCS0 (kp1, kp2, Laux, C1,0, r1) σ, kp1,0, kp2,0 −−−−−−−−→ check C, G2, trans
h0,2← PHashCS0 (kp′1, kp2′, Laux, C2,0, r2) h0,1← HashD−CS0
hx,1← HashEGx (kh1,0, Laux, C1, C2)
hx,2← HashEGx (kh2,0, Laux, C1, C2) hx,1← PHashD−EGx
sk1= h0,1hx,1, sk2= h0,2hx,2 sk1= h0,1hx,1
Fig. 19: Two-Server KOY [127] using D-SPHF
The client sends the projection keys in a third round together with a one-time signature on the session transcript to the servers. The protocol is sketched in Figure 19 using our notation for D-SPHFs. Note that we have to move and rename several computations but do not modify the protocol. The ElGamal encryption of the password of server Si, ˆCi ← EncEGpki(g
pwdi; r
i) is precomputed and stored on Sj, j ̸= i, j ∈ {1, 2}.
Eventually, the client computes hash values using the PHash0 function of the GL-D-
SPHF scheme on CS ciphertexts and the Hashx function of the D-SPHF scheme on
ElGamal ciphertexts. Further, the servers execute the HashD
0 protocol of the distributed
GL-D-SPHF scheme on Cramer-Shoup ciphertexts and the PHashD
x protocol of the
D-SPHF scheme on ElGamal ciphertexts.
Security Analysis Security of the 2KOY protocol against passive adversaries follows
immediately from [127, Theorem 1] as we do not change the protocol in Figure 19 However, Katz et al. [127] need additional mechanisms to prove their protocol secure against an active adversary. They add witness-indistinguishable Σ-protocols to the PHashDx and HashD0 protocols that prove correctness of their messages. Without giving a proof it seems that Theorem 8 also holds for the two-server KOY instantiation
without additional mechanisms. Examining the proof of [127, Theorem 2] shows that
the additional steps are only necessary to conduct the proof without actually giving additional security. This shows the power of D-SPHF as they allow for much simpler proofs of multi-party protocols. Furthermore, with the proposed framework the protocol becomes more efficient than the two-server KOY protocol as it needs only two rounds
instead of three and does not need correctness proofs in the distributed hash and projection protocols.
5
Universally Composable Two-Server PAKE
Using Distributed Smooth Projective Hash Function allows to construct efficient 2PAKE protocols that are secure in the UC-framework. This follows the same approach as PAKE protocols from SPHF protocols, which use the properties of SPHFs to construct efficient PAKE protocols in the UC-framework. In this section we propose the first UC functionality for 2PAKE protocols and give an efficient instantiation using a variant of D-SPHF proposed in Section 3.
Before diving into technicalities we want to discuss 2PAKE and security guarantees it should provide. We discuss informally several security requirements for 2PAKE protocols, which is then the basis for the ideal functionality F2PAKE defined later. First
note that the adversary has full control over the communication channel between client and servers as usual but communication between the two servers is confidential. The first and foremost security requirement of password protocols is security against
offline dictionary attacks and therefore has to be fulfilled by 2PAKE protocols as
well. In particular, no eavesdropping adversary must be able to perform an offline dictionary attack on the exchanged messages. Further, a malicious server must not be able to impersonate a registered client in a 2PAKE execution. An attacker, even with knowledge and capabilities of one of the two servers, must have success probability that is not significantly better than the success probability of a brute-force attacker when running a 2PAKE protocol on behalf of a registered client. The BPR-M game-based security notion for PAKE and 2PAKE, which is derived from the AKE security notion, captures security by testing whether an attacker is able to distinguish between a real session key generated by a (two-server) PAKE protocol, and a randomly chosen session key. This implies in particular that the client agrees on two independent session keys with the two servers in the 2PAKE setting. UC-security in contrast requires simulatability of a (two-server) PAKE protocol and is therefore harder to instantiate because the protocol has to be simulated even in case the adversary is able to guess the correct password (in which case the game-based model simply aborts the protocol execution and declares the adversary won the game).
We want to further elaborate the difference between 2PAKE protocols where both servers compute the same key, compared to a 2PAKE protocol where the servers compute different keys. Note that asymmetric key generation may also imply that only
5 Universally Composable Two-Server PAKE 149
one server calculates a key while the second server only assists in the computation. In the symmetric setting both servers calculate the same session key as result of the 2PAKE protocol. Even though it is the first natural extension to the single server PAKE scenario, to the best of our knowledge no such protocol has been proposed yet. This may be due to the fact that corruption of a single server compromises the session key of any execution of a 2PAKE protocol that involves this server. In the asymmetric setting both servers generate different session keys as result of the 2PAKE protocol, possibly none. Katz et al. [127] proposed the first password-only 2PAKE protocol provably secure in the standard model, based on the Katz-Ostrovsky-Yung (KOY) protocol [128]. While their protocol as well as the 2PAKE framework from the previous section is symmetric in its execution the client computes two independent session keys, one with each server. Other asymmetric 2PAKE protocols have been proposed [124, 198] where the client interacts with only one server.
In this section we stick to the asymmetric setting where only one server computes a session key. This however can be easily extended to a 2PAKE protocol that computes an independent session keys for each server. To this end we propose the first UC functionality for 2PAKE protocols, which brings all benefits UC-security carries in the PAKE setting such as universal composability, security with arbitrary (related) password choices, security on execution with non-matching password (shares), and so on. For a comprehensible overview of advantages using UC in the PAKE setting we refer to Canetti et al. [62]. To this end we extend D-SPHF to Trapdoor Distributed Smooth Projective Hash Function (TD-SPHF) first.