imperiopolis

Joined 15 years ago

Karma

Submissions

Member since

Jul 20

Recent submissions

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.

Comment · 2 years ago

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.

Comment · 2 years ago

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

Comment · 2 years ago

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.

Comment · 2 years ago

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!

Comment · 2 years ago

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.

Comment · 12 years ago

Savant Systems – Hyannis, MA

Savant is a home automation company, based heavily on the Apple platform. A Mac Mini or Linux host is used as the server to control your home, in tandem with our custom AV switches, lighting systems, and HVAC systems. Once setup, your home can be controlled from our iOS apps, our traditional remotes, or our new Android based universal remote.

I'm a Software Engineer at Savant, and working there is definitely a great experience. You may fill one of these roles below, but you'll get to work on a wide variety of projects, regardless your role. To give you a brief picture, day-to-day, I will work on firmware, Mac apps, iOS apps, Node.js web apps, and daemon processes that run on Mac and Linux.

We're looking to fill the following roles ASAP: - Senior iOS Developer - Junior iOS Developer - Android Developer - Android Platform Software Engineer - Firmware Engineer - Linux Software Engineer - Media Software Engineer - Web UI Developer - Junior/Mid-Level Web Developer

If you want to read more about the positions or apply, visit our careers page here: http://www.savantsystems.com/careers.aspx

If you have any questions, feel free to email me at

Comment · 15 years ago

Support the older rev for a while (with multiple devices, not upgrading, blobs). When apple stops supporting an older device, next major release shifts the target to whatever the minimum iOS was on the next newest device when it shipped (usually just a few revs higher). This way, we support whatever hardware apple supports on every possible iOS. iOS 5 will make this trickier.

Also, if there are significant bugs on apples part in a particular iOS that hamper our app, we'll drop it early.