Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What We Do in the /etc/shadow – Cryptography with Passwords

soatok.blog

Post reply on HN
Print view View original

31–34 of 34 posts

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#31

Post by Oreko »

Oreko wrote: post #24

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…

Turns out I misread part of the protocol.

I mixed up "b" stored by the server in the registration phase and the "b" used in the online phase. In that case, the adversary can't compute either b * C or c * B (by probably just CDH).

This being said, there's a more technical problem with the protocol as-is with how the OPRF is used. Currently, the adversary can malleate the OPRF messages resulting in a valid/invalid session between two honest parties without the simulator being able to distinguish between the two cases. This comes from the perfect blinding property of 2hDH and is discussed in the OPAQUE paper[1].

There may be other problems, but _most_ of the protocol passes a quick smell test.

Sorry for any confusion!

-- EDIT --

I'm not really surprised that this problem came out as the JKX compiler is quite nuanced (more so than the paper immediately lets on). So I definitely suggest walking through the proof before applying this protocol anywhere; however, the current protocol seems like a good jumping off point. I think there also needs to be a clear reason to use a SPEKE derivative as the aPAKE building block.

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#32

Post by Oreko »

Oreko wrote: post #29
cendyne wrote: post #28

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…

Another confusion on my part, above the protocol Sc00bz writes:

" Client without password has:

      idC = client identity

      P = hashToPoint(p)

      c

      S = s * P

      Reg = reg * G (reg = registration private key)
"

Re: What We Do in the /etc/shadow – Cryptography with Passwords

#33

Post by _448 »

some_furry wrote: post #27
_448 wrote: post #26

Earlier quoted context omitted.

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?

crypto_box_seed_keypair() Or for signatures, crypto_sign_seed_keypair(). Use the output of Argon2 as the seed.

Thank you very much. That was really helpful!
Post reply on HN