1 of 17

Lec 16: Asymmetric PAKE

2 of 17

User-server setting

  • User (a.k.a. client): you(r brain), storage very limited
  • Server: web server
    • Larger storage space
    • Can be compromised

3 of 17

PAKE in the client-server setting…

  • Server compromised → password leaked straight away!

  • Such attack not modeled in PAKE definition
    • Implicitly assuming no party compromise (all security guarantees lost if party compromise)

 

 

 

 

4 of 17

Asymmetric/Augmented PAKE (aPAKE)

  •  

 

 

 

 

5 of 17

  •  

6 of 17

What if…

  •  

 

 

 

 

7 of 17

  •  
  •  

8 of 17

Naïve aPAKE construction

  •  

 

 

 

 

 

 

PAKE

9 of 17

  • Adversary can impersonate user after compromising server

 

 

 

 

 

PAKE

10 of 17

  • Compromise server, impersonate server → inevitable (adversary simply runs server’s algorithm), has to be allowed
  • Compromise server, impersonate user → should be prevented
    • … unless adversary does an offline dictionary attack to find password
    • … or succeeds in an online guessing attack

11 of 17

Summary

  •  

12 of 17

UC Functionality for (s)aPAKE�[GMR06, JKX18]

13 of 17

First attack: offline dictionary attack

  •  

14 of 17

 

  •  

15 of 17

aPAKE functionality

  •  

16 of 17

 

  •  

17 of 17

References

  • [GMR06] Craig Gentry, Philip MacKenzie, and Zulfikar Ramzan. A Method for Making Password-Based Key Exchange Resilient to Server Compromise. In CRYPTO 2006.
  • [JKX18] Stanislaw Jarecki, Hugo Krawczyk, and Jiayu Xu. OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks. In EUROCRYPT 2018.