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

Juicebox: Squeezing the hassle out of encryption key recovery

juicebox.xyz

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#11

Post by throwiforgtnlzy »

ggm wrote: post #4

It's a shame key escrow has become a tainted concept, mired in "government has my keys" because a mechanism to store offline a cold copy of keying material and recover it is a good thing to have available.

"Key escrow" by encrypting secrets yourself with trusted tools and storing the result in various object stores. Problem solved.

Also solved by on-prem secrets and password managers without cloud features or dial-home.

Trusting a new third-party with their new and likely unproven construction is a recipe that has failed spectacularly over and over again.

It's possible, but it's very, very difficult and, like email or DNS, becomes a kind of commoditized utility that rarely/never changes.

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#12

Post by themoonisachees »

ongardie wrote: post #6
XMPPwocky wrote: post #3

Earlier quoted context omitted.

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?

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…

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?

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#14

Post by imperiopolis »

themoonisachees wrote: post #12
ongardie wrote: post #6

Earlier quoted context omitted.

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…

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).

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#15

Post by imperiopolis »

_factor wrote: post #13

Interesting idea, but the logging aspect still leaves it up to the shard holder to perform. This essentially reduces counting to a promise.

Programmable HSMs, with verifiable software (e.g. via a key ceremony), removes the need to trust a shard holder to do counting correctly. You know what software they're running, so you can verify it works as designed.

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#16

Post by themoonisachees »

imperiopolis wrote: post #14
themoonisachees wrote: post #12

Earlier quoted context omitted.

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!

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#17

Post by franky47 »

One of my first blog posts was about a similar system, though much simpler/naive and based on trusting an email address to distribute shards.

Its failure point boiled down to letting the user save the other shard. Maybe a 3-shard scheme could help redundancy and loss tolerance.

https://francoisbest.com/posts/2020/password-reset-for-e2ee-...

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#18

Post by belltaco »

imperiopolis wrote: post #2

Author here, happy to answer any questions! TL;DR we're sharing an open-source encryption key recovery protocol that provides high security coupled with a user-friendly design, to make encryption further accessible to larger numbers of people. What we've built leverages programmable HSMs, distributed cryptography, and a user-friendly PIN-based recovery process to simplify key recovery without compromising security.

[dead]

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#19

Post by simplify »

imperiopolis wrote: post #2

Author here, happy to answer any questions! TL;DR we're sharing an open-source encryption key recovery protocol that provides high security coupled with a user-friendly design, to make encryption further accessible to larger numbers of people. What we've built leverages programmable HSMs, distributed cryptography, and a user-friendly PIN-based recovery process to simplify key recovery without compromising security.

Juicebox's design of distributing secrets to n independent services sounds similar to Lit Protocol's threshold signature schemes. Is this in the same problem space or no?

Re: Juicebox: Squeezing the hassle out of encryption key recovery

#20

Post by DerekRodriguez »

It looks like an interesting approach but it seems conceptually complex and difficult for general users to consume. Can you explain how this differs from Gridlock which is an app that allows any level user create a network of storage devices using threshold cryptography?
Post reply on HN