Juicebox: Squeezing the hassle out of encryption key recovery(juicebox.xyz)
juicebox.xyz
Juicebox: Squeezing the hassle out of encryption key recovery
https://www.juicebox.xyz/blog/key-to-simplicity-squeezing-the-hassle-out-of-encryption-key-recovery
24 comments
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 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.
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).
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!
Besides "how do we use this" any word on the authors of this project? I did a very cursory search of the two contributors and there was very little I could find that would reassure me in using such a sensitive tool. Could well be my heightened paranoia after recent events.
Ideally you don't have to trust us! Code is open source on GitHub, protocol is published in the whitepaper, and all has been independently audited.
If you have specific concerns, happy to talk them through!
If you have specific concerns, happy to talk them through!
The team is here, includes creator of Signal, among others: https://www.juicebox.xyz/contributors
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?
It’s a different problem space. Lit seems very focused on the MPC use case. They are using some similar, albeit less strong cryptographic techniques, but at their core (based on https://developer.litprotocol.com/v3/resources/how-it-works) they seem focused on MPC, blockchain applications, and more social key distribution.
Juicebox is very focused on how does an individual user manage their private key for one service, in a simple and user-friendly way, without any compromise in security. Think like your keys for Signal, WhatsApp, or any other E2EE service. It could also be used to manage a wallet private key for a noncustodial wallet.
As far as I can tell, Lit also manages all the nodes available to you (even if they don’t personally run them). There’s not a freedom for you to run your own nodes. This is the most important thing for this kind of distributed cryptography to be used securely, and something Juicebox supports by default – all our server code is available on GitHub and we encourage people to host their own realms to build networks with appropriate trust characteristics.
Juicebox is very focused on how does an individual user manage their private key for one service, in a simple and user-friendly way, without any compromise in security. Think like your keys for Signal, WhatsApp, or any other E2EE service. It could also be used to manage a wallet private key for a noncustodial wallet.
As far as I can tell, Lit also manages all the nodes available to you (even if they don’t personally run them). There’s not a freedom for you to run your own nodes. This is the most important thing for this kind of distributed cryptography to be used securely, and something Juicebox supports by default – all our server code is available on GitHub and we encourage people to host their own realms to build networks with appropriate trust characteristics.
It's the same space but most "solutions" in the space (like Lit Protocol) are actually custodial solutions parading as non-custodial. If you look closer at Lit Protocol, you will see that their nodes are unknown and unamed providers. Reading between the lines, it's just Lit hosting everything.
EDIT to previous comment.
I actually just has a call with David from Lit Protocol. He patiently explained some of the nuanced pieces of Lit Protocol. A lot of this information is out there but they are moving so fast that it's hard to find. They are going to update their docs to make it more apparent but they have named their providers and appear to have a robust distributed network for key storage. Sorry for the hasty comment! It looks like Lit Protocol is one of the few non-custodial and resilient systems out there.
I actually just has a call with David from Lit Protocol. He patiently explained some of the nuanced pieces of Lit Protocol. A lot of this information is out there but they are moving so fast that it's hard to find. They are going to update their docs to make it more apparent but they have named their providers and appear to have a robust distributed network for key storage. Sorry for the hasty comment! It looks like Lit Protocol is one of the few non-custodial and resilient systems out there.
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-...
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-...
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?
People would integrate the client SDK into their applications and/or websites, it's not intended for end users to consume directly.
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.
Making encryption more convenient for everyone is definitely a good thing. Some people will always have that paranoia around letting keys out of their hand, but for the rest of us this protocol aims to reduce the need to trust any one service with your key material by distributing it across independent distrusting services.
"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.
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.
Interesting idea, but the logging aspect still leaves it up to the shard holder to perform.
This essentially reduces counting to a promise.
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.
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.