Hacker News Reader

Comment by XMPPwocky | Hacker News Reader

I'm not a cryptographer- what's the attack/failure mode of "standard HSM key recovery, but the 'PIN' sent to each realm is actually HMAC(some_identifier_for_each_realm, PIN), and each realm stores just one share of the secret"- i.e. what motivates the use of OPRF here instead of just HMAC to prevent a realm from basically pass-the-hash-ing the user's PIN to get shares from other realms?

View on HN

The issue if realms stored HMAC(realm_id + PIN), where PINs are presumed to be low-entropy, then an individual realm could brute-force the PIN. Specifically, an adversary with access to a single realm's database could enumerate PINs, run them through the HMAC along with the realm ID, and test locally whether that's the correct PIN. That would already be bad because users might reuse PINs across services. Then, if the adversary had valid auth tokens for other realms, they would be able to use that PIN to recover the secret shares from other realms and reconstruct the secret.

The Juicebox protocol is designed to prevent this. A realm can't individually test whether or not a PIN is correct.

Note: I'm a former employee of/contributor to Juicebox.

Ah, of course, that makes sense- thanks for the answer!

What work does "individually" do in this last sentence? Can 2 evil services collaborate (or more realistically 2 non-evil services get breached) to extract part of the secret? What is the mechanism keeping me from setting up n realms and extracting secrets from their shared info?

Yes, that is the work "individually" is doing here – multiple realms (services) could collude to combine shards and attempt to extract secrets.

However, programmable HSMs, with verifiable software (e.g. via a key ceremony), minimize this form of collusion. The shards they hold can't be extracted by a malicious operator, at least without substantial effort (requiring HSM hardware vulnerabilities).

Interesting. Thanks for the explanations!

Reply on news.ycombinator.com