Let’s Talk about PAKE (2018)
blog.cryptographyengineering.com
Let’s Talk about PAKE (2018)
1–10 of 70 posts
Re: Let’s Talk about PAKE (2018)
#2Relatedly, a recent post on SRP (the most commonly used PAKE) and how it's worse in all cases than PAKEs derived from SPEKE:
Re: Let’s Talk about PAKE (2018)
#3There's some dust on it, but I made a proof-of-concept OPAQUE implementation some years back (disclaimer: this was done for educational, not security, purposes). The README has some good discussion of the various components of OPAQUE, and I'd argue the code (mostly C) is quite readable. If folks are interested, I'd encourage them to take a look: https://github.com/GeorgeLyon/Opaque.
Re: Let’s Talk about PAKE (2018)
#4A few years ago, I saw this article and wrote https://github.com/cretz/gopaque as a learning exercise (meaning I am no cryptographer, code has not been vetted, probably outdated, etc). See https://pkg.go.dev/github.com/cretz/gopaque/gopaque for docs on how it abstracts registration and authentication.
Re: Let’s Talk about PAKE (2018)
#5(2018)
Re: Let’s Talk about PAKE (2018)
#6Why did he recommend OPAQUE over others like SPAKE2?
Re: Green's question on why it is not more widely deployed, I assume it is since TLS already is common and PAKE would be an additional layer of encryption on this? Or is his proposal use PAKE for auth then discard keys, use TLS normally?
Re: Let’s Talk about PAKE (2018)
#7One of the reasons I love reading about crypto algorithms is that there is a certain elegance and the pleasure of solving an intellectual puzzle when you read them.
I felt this way when I first read about RSA and public key encryption, and Shamir's secret sharing algorithm
This article gave me the same feeling with regards to OPAQUE.
I don't know that I will ever personally implement the algorithm, but just knowing about it is gives me a certain nerdy pleasure.
Thanks for the great writeup.
Re: Let’s Talk about PAKE (2018)
#8I probably would never try to implement this on my own website. My login pages don't use JS, so unless the browser did the work for me, it's complexity that I'm never going to understand running on the most crucial page on my site.
Moreover, though, users run so much shit in their browsers. More than half of the logged errors on my site are from user scripts and browser extension content scripts doing lord knows what. They can all just slurp the value out of the DOM, no questions asked. Never mind my CSP, HTTPS, and all of the effort I go to making my server environment secure and safe. The weakest link is not the password getting sent to my servers (over HTTPS), it's the utter free-for-all happening on the page in the first place.
Re: Let’s Talk about PAKE (2018)
#9Frank Denis has an elliptic curve PAKE built on top of libsodium called CPACE. The implementation is less than 150 lines of C
Re: Let’s Talk about PAKE (2018)
#10Relatedly, a recent post on SRP (the most commonly used PAKE) and how it's worse in all cases than PAKEs derived from SPEKE: https://tobtu.com/blog/2021/10/srp-is-now-deprecated/
Curious to know your thoughts on: "...what are [some] problems [tptacek has] with password-authenticated key exchange?"
https://news.ycombinator.com/item?id=18260407
Thanks.