(2018)
Prior commentary: https://news.ycombinator.com/item?id=18259393
Thanks! Macroexpanded:
Let’s talk about PAKE - https://news.ycombinator.com/item?id=18259393 - Oct 2018 (98 comments)
Let’s Talk about PAKE (2018)
61–70 of 70 posts
Re: Let’s Talk about PAKE (2018)
#62So, OPAQUE stands for what? Or, do we not care anymore? :) Apparently, it's based on "aPAKE" which stands for "Asymmetric PAKE", but I guess OPAQUE is an acronym that sounds cool.
OPAQUE was chosen because the name OPAKE already existed, and it's an Oblivious PAKE. So, it does not form an acronym.
If it's not an acronym, why is it all caps?
Re: Let’s Talk about PAKE (2018)
#63Earlier quoted context omitted.
OPAQUE was chosen because the name OPAKE already existed, and it's an Oblivious PAKE. So, it does not form an acronym.
If it's not an acronym, why is it all caps?
Well, if it was just named opaque that would be confusing because that's a word meaning the opposite of transparent.
Naming things is hard for most people. Where some people are imaginative enough to name their stream cipher ChaCha20, the best you can expect from many engineers is something like PADMÉ (a padding scheme).
Re: Let’s Talk about PAKE (2018)
#64Earlier quoted context omitted.
Are you sure that's how Matrix E2EE works? In my experience, to access encrypted chats after logging in for the first time I have to verify the new session by performing a synchronous prompt-verify sequence from an existing session, and I don't remember setting any encryption passphrase at all. What gives? Are we just using different defaults or clients or something?
Disclaimer: I'm not an expert in this stuff, just a 3rd party client developer who is interested in the topic. AFAIK, there are two ways to validate a new device in Matrix. It sounds like you're describing the interactive device validation procedure. After that, your two devices trust each other, and the old device can "cross sign" the public key of your new device, so others can trust it too. Personally for me, even…
Interactive verification gets you access to all secrets too.
It's a question of having enabled key backup without which you cloud loose keys
Re: Let’s Talk about PAKE (2018)
#65What is the benefit of PAKE over this: https://datatracker.ietf.org/doc/html/rfc2289
PAKEs are secure over insecure channels. Also I'm pretty sure for RFC2289 the server stores a password equivalent. If you neither care about creating an encrypted session nor being secure over an insecure channel, then you should use SCRAM. With SCRAM, the server stores a password hash equivalent. Meaning an attacker needs to crack the password before they can login as them.
Re: Let’s Talk about PAKE (2018)
#66Library for PAKE (but not OPAQUE specifically) in Go: https://github.com/schollz/pake
This was recently broken then fixed. I heard about it because of that then looked at it and broke it again. I only checked one thing and it was wrong. I would not trust this. Also SPEKE based PAKEs are better.
Re: Let’s Talk about PAKE (2018)
#67Why 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?
I don't know why OPAQUE was chosen in this 2018 article, but OPAQUE was eventually selected as CFRG's preferred asymmetric PAKE PAKEs are a fairly specialist protocol. If you don't need to use human memorable passwords then you should not do so. There are cases where you can't bootstrap some other means but you do have, or can agree, a human memorable password and PAKEs are a good choice then. So there are lots of pr…
OPAQUE was chosen because it was new and had the new "no precomputation" property. Which can be added to better PAKEs by adding an OPRF vs just sending the salt. OPRFs can be added without adding an extra trips to the protocol.
> the right thing is WebAuthn.
True, but if a good PAKE is added to TLS (it won't) then your logged-in sessions are protected by needing to solve a DLP for every password guess (ie "quantum annoyance", a property of a good PAKE). This does assume quantum computers become a thing.
> WiFi (WPA3)
They used the worst PAKE available. They even used the wrong class of PAKEs (balanced vs unbalanced (or augmented "aPAKE")).
> and it's an improvement over prior approaches.
No, it was broken but maybe it's fixed? The original version is basically "WEP 2.0" and they likely have backwards compatibility because "oops, we published a spec with a known to be broken PAKE... but it was an IEEE PAKE, don't blame us".
Re: Let’s Talk about PAKE (2018)
#68Why 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?
I was team SPAKE2 based PAKEs, but I now know that SPEKE based PAKEs are better.
P.S. SPAKE2 is a balanced PAKE vs augmented PAKE (or unbalanced PAKE) like OPAQUE and SPAKE2+ (and SPAKE2+EE).
Re: Let’s Talk about PAKE (2018)
#69So, OPAQUE stands for what? Or, do we not care anymore? :) Apparently, it's based on "aPAKE" which stands for "Asymmetric PAKE", but I guess OPAQUE is an acronym that sounds cool.
> Apparently, it's based on "aPAKE" which stands for "Asymmetric PAKE"
It is an "aPAKE" which stands for "augmented PAKE". An aPAKE is client-server vs peer-to-peer. The original PAKE was peer-to-peer then augmented to be client-server. A peer-to-peer PAKE is called PAKE or balanced PAKE, but "PAKE" could be use generally to mean client-server and/or peer-to-peer PAKE. aPAKEs are sometimes called unbalanced PAKEs.
I've heard people say asymmetric PAKE and symmetric PAKE (for client-server and peer-to-peer), but this causes confusion with asymmetric and symmetric cryptography. Thus should not be used. And was likely from a misunderstanding around what "a" meant in "aPAKE".
Oh there is a "double augmented PAKE" which I recently figured out a use case for that, WiFi. Also technically OPAQUE is a "double augmented PAKE", but only defined as an augmented PAKE.
(Sorry for the history lesson)
Re: Let’s Talk about PAKE (2018)
#70Fun fact: World of Warcraft used SRP4 for a long while (I'm not sure if it does anymore). That's a pretty big deployment. But this article will be useful; I have something unreleased that does password authentication by dumping the salt to the user, just out of ease of implementation. I'll probably take another look at it.
Super fun fact: Blizzard's (ie World of Warcraft's) safe prime was 256 bits which was known to be broken at the time, but no one really knew this until they got hacked and their database got leaked.
Super-duper fun fact: Before Blizzard moved to SRP, they fubared SHA1 by shifting 1 by a variable vs shifting a variable by 1. This meant that after the shift it was one of 32 values. Which let's one crack or collide the "XSHA1" hash in seconds. I was going to say just google "XSHA1" and you'll get my website with attack code but I think Google de-listed it... maybe I should link to Github vs a zip with code and a .exe... or make my site mobile friendly (for better ranking).
P.S. I thought Blizzard used SRP6a... although I'm not familiar with every SRP version. I looked at the early versions of SRP (I think I got to v3) and they were obviously broken (from the understanding of what a PAKE threat model should be).