[arcurn]

Hi all, founder of Evervault here.

We're building encryption infrastructure for developers. At the core of this infrastructure is our encryption engine, E3.

Today, we’re excited to share how we built it. Our blog[0] goes into more detail, but there's a quick summary below. We'd love to answer any questions you have!

    - E3 is a simple encryption service for performing cryptographic operations with low latency, high scalability and extreme reliability. 
    - E3 is where all cryptographic operations for Evervault services happen. 
    - E3 ensures that Evervault never handles key material in environments that are not provably secure. 
    - E3 is written in Rust.

We’re grateful to the AWS Nitro Enclaves team for welcoming us to be a closed preview design partner, and are delighted to have been featured in the Nitro Enclaves Press Release[1] and on the Landing Page[2].

Shane

[0]: https://evervault.com/blog/e3

[1]: https://press.aboutamazon.com/news-releases/news-release-det...

[2]: https://aws.amazon.com/ec2/nitro/nitro-enclaves/

[dumbfounder]

How does the customer prove that their data is secure? It seems like you can prove your own environment is secure (as long as you trust the TEE), but the customer is still trusting you to run in that environment, no?

[arcurn]

Thanks for the question! I addressed some of this in an answer above: https://news.ycombinator.com/item?id=28129362

The summary version is that we share source code and platform control registers (PCRs) with enterprise customers who need these kind of security guarantees, and also expose the Nitro Enclaves attestation documents to them so they can establish secure channels with E3 in a provable way.

[dannyw]

So basically: as a retail consumer, we can't trust you. You might as well as be a malicous honeypot. Scan and log for cryptocurrency keys and then "get hacked" and retire in Thailand.

Or maybe you're a government honeypot, like Crypto AG, or the numerous other cryptography companies that turned out to actually be mass decryption companies.

If you're building an encryption company, the onus is on you to prove it. BitWarden for example is fully open source, and you can self host the server.

[arcurn]

Hey Danny, correct — we do not currently expose attestations to consumers. Over time, this is something we absolutely plan on doing.

One thing worth focusing on is that Evervault is built for developers. Developers do not have to build using Evervault, so a developer using Evervault to mislead their customers about their security isn't something we focus heavily on. There are much easier ways for developers to mislead customers about their security, but that's a conversation for another time :)

I completely agree re: the onus being on us to prove it. It's something we're actively trying to improve, and sharing how we built E3 is just the beginning of us sharing more about how we design & build. Transparency is an existential requirement for us to become a standard part of the developer toolkit. Watch this space!

[0des]

I agree, the justifications in this thread rely a lot on inherent trust of the facilities provided. I get that your example is somewhat a bad-case-scenario, but today nothing is a surprise, and it's entirely possible as unfortunate as that is.

[kop316]

Hello! If I may, some (hopefully constructive) criticism:

- I skimmed the article, and I honestly am not sure who the customer is. AWS customers I suppose? It would be nice to have a quick "TL;DR" section so I can quickly tell if I am the right customer. (I'm also not an AWS customer, so maybe I just don't understand the jargon).

- A big pet peeve of mine when reading security related things is not seeing security assumptions. It would be nice to understand what your infrastructure does and does not protect against.

[arcurn]

Hi there, thanks for the question!

Our customers are mostly developers working at startups which process high volumes of sensitive data (things like payment details, healthcare data, credentials etc.). We abstract away all of the infrastructure that E3 runs on, so we don't have any requirements for where our customers our hosted. Our customers run on a very diverse range of stacks/clouds, so being cloud-agnostic was a key design requirement.

The core security assumption with Evervault is that your API key is reasonably well managed. API keys can be easily rotated in our dashboard, but having encrypted data and an Evervault API key could potentially lead to data leakage. Over time, we plan on adding some cool features around data leakage whereby we can proactively block data exfiltration/leakage. More on this soon!

A simple model for how security with Evervault works is: you store encrypted data, but not keys; Evervault stores keys, but no data. This creates a nice dual-responsibility model which far exceeds what most companies can do today.

Feel free to email directly if you have any other questions! I'm on [e-mail]

[kop316]

Fair enough.

If I may say, that would be great to have as an up front summary!