21–30 of 34 posts
I notice the article stopped citing examples of large-scale password cracking after the introduction of PBKDF2. Technical tours through the winding passages of password management in services is fun and all, but I wonder if this is ultimately contributing more to bad habits than good ones. Readers capable of implementing something like OPAQUE will already have a pretty good handle on most of what's written here. All…
What is the recommended way of deriving a private key from a password and/or passphrase? Any pointers to relevant literature will also help.
Typically you don't need to know much more than what the libsodium docs tell you: https://libsodium.gitbook.io/doc/password_hashing
It uses the Argon2 algorithm (RFC9106).
I have studied Argon2 and in my opinion it really is an improvement over the older methods.
Earlier quoted context omitted.
I just hit a website I know has an entirely default config on the free plan as https://website/q=cat /etc/shadow and got the same exact error page.
So much for CloudFlare's stance on free speech, I'm being censored for comedy! (The title is a wordplay on What We Do in the Shadows .) Joke aside, I can understand why, generally, protecting from /etc/shadow disclosures is a good default, but it should be possible to disable this particular protection. If anyone knows how, that'd be good to share. EDIT: A bypass has been discovered https://infosec.exchange/@jsmall/1…
I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard if you believe in the compiler provided in the JKX18 paper[1] and you believe that B-SPEKE is a UC-secure aPAKE but it's important to note that the JKX compiler is not proven secure against the updated functionality from their revisions. Further, I don't believe that B-SPEKE has a security proof in any model let alone the UC model.
But I can say for certain that the currently described protocol is not a secure saPAKE as it doesn't prevent an adversary from impersonating a client after stealing the server's password file.
The adversary learns (B, salt, P, C, s, b, regMAC) and needs to produce (a * P, H(idC, idS, A, B, a * B, c * B, s * A))
a is uniformly sampled, so the adversary knows a * P, A, B, a * B, and s * A. We're missing c * B, but this is just b * C which we know. So the adversary can produce all messages required and arrive at the server's key.
This may not be a security guarantee that you need for your use case, but I cannot recommend Double BS-SPEKE as an saPAKE (or even an aPAKE) until we see a formalized analysis of its guarantees.
[1] OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks https://eprint.iacr.org/2018/163
--- EDIT ---
I just came across the original talk https://www.youtube.com/watch?v=gopo2FI9epw using the term "doubly augmented" and I'll update this post soon.
I'm still not sure what "doubly augmented" means, but the talk seems to conflate the security properties of OPAQUE and double BS-SPEKE as well as listing doubly augmented as a subset of augmented PAKEs.
Earlier quoted context omitted.
There's a reason for this - having /etc/shadow in the title breaks searching from Algolia search due to a WAF. eg try this https://hn.algolia.com/?query=What%20We%20Do%20in%20the%20%2...
That WAF needs to be tuned. If they’re worried about the possibility of a local file read that can disclose /etc/shadow, there are much bigger issues.
What is the recommended way of deriving a private key from a password and/or passphrase? Any pointers to relevant literature will also help.
Typically you don't need to know much more than what the libsodium docs tell you: https://libsodium.gitbook.io/doc/password_hashing
And is there a way to derive a public key using a derived private key, say, for example, by using ECC?
Earlier quoted context omitted.
Typically you don't need to know much more than what the libsodium docs tell you: https://libsodium.gitbook.io/doc/password_hashing
Thank you for the link! I will go through it. And is there a way to derive a public key using a derived private key, say, for example, by using ECC?
Or for signatures, crypto_sign_seed_keypair(). Use the output of Argon2 as the seed.
Hi, I perform research in the area of PAKEs. I'm not a "foremost expert" but I know a bit. Before I start, I don't believe that it's standard to use the term "doubly augmented PAKEs". Instead, I'll use the more accepted shorthand "saPAKE" for "strong asymmetric PAKE". I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard…
Hi, I perform research in the area of PAKEs. I'm not a "foremost expert" but I know a bit. Before I start, I don't believe that it's standard to use the term "doubly augmented PAKEs". Instead, I'll use the more accepted shorthand "saPAKE" for "strong asymmetric PAKE". I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard…
The "augmented" label confused me a lot too. I saw Steve Thomas's presentation in person at DEF CON and could not find material online using that phrase outside of his materials.
Sc00bz made a comment[1] on reddit describing what "doubly augmented" means where they succinctly describe it as
"A doubly augmented PAKE is where both sides can store data to authenticate with eachother but not themselves."
This mirrors the definition of aPAKE and makes sense, but this sounds more like the security property provided by CRISP[2]. This doesn't make sense in the context of double BS-SPEKE as the client inputs their password in the clear which can be used to generate the server's storage without any "guessing".
[1] https://old.reddit.com/r/crypto/comments/zy8w3y/what_we_do_i...
[2] CHIP and CRISP: Protecting All Parties Against Compromise through Identity-Binding PAKEs https://eprint.iacr.org/2020/529
Earlier quoted context omitted.
The "augmented" label confused me a lot too. I saw Steve Thomas's presentation in person at DEF CON and could not find material online using that phrase outside of his materials.
Augmented is a common label for these kind of PAKEs. Generally speaking, asymmetric, verifier-based, and augmented are all three interchangeable. Sc00bz made a comment[1] on reddit describing what "doubly augmented" means where they succinctly describe it as "A doubly augmented PAKE is where both sides can store data to authenticate with eachother but not themselves." This mirrors the definition of aPAKE and makes se…