arcurn

7 ms·

1.
A Guide to Good DX, Part 1: Introducing DXmas(evervault.com)
2 points by arcurn 4y ago|0 comments
2.
Encryption Firm Evervault Launches Service to Protect Crypto Seed Phrases(coindesk.com)
2 points by arcurn 5y ago|0 comments
3.
by arcurn 5y ago
This is very helpful — thank you! On #2, we have carried out security audits with Cure53[0] and others, which we are happy to share. We also have a root of trust which is provably embedded in the AWS Nitro System[1] #1 and #3 are great sugg
4.
by arcurn 5y ago
This is mostly true, but even if somebody manages to get access to an application runtime there won't be a major data leakage issue using Evervault because all data has been encrypted using a key that our customers don't host. All
5.
by arcurn 5y ago
Thanks for pointing this out. I agree that the tone here doesn't align with what we want to commit to with our customers. We'll do some work on improving this (probably removing the entire clause around waiving a right to claim) a
6.
by arcurn 5y ago
We encrypt data at the field level so your infrastructure (including code and database) never handles sensitive data in plaintext. We also help you manage the decryption keys, so rogue developers or data breaches are as close to inconsequen
7.
by arcurn 5y ago
Thanks for the comment — I understand the sentiment, but we invest a lot more effort in trying to persuade security pros and cryptographers through the technical and security features of the product itself. The people making the decision to
8.
by arcurn 5y ago
This is a great suggestion, thank you! We'll get to work creating this.
9.
by arcurn 5y ago
Hi! Founder of Evervault here. You're totally right in saying the number of developers who are actively integrating encryption is pretty small as of today. What we're trying to do is improve developer experience to a point where e
10.
The Evervault Encryption Manifesto(evervault.com)
3 points by arcurn 5y ago|0 comments
11.
by arcurn 5y ago
Yep, but there will be no variance in timing from the end user's perspective (regardless of what payload they send to E3) because neither encryption results nor timing data get returned to the end user.
12.
by arcurn 5y ago
Yep! All dependencies etc. are cached locally on a build machine so everything's deterministic.
13.
by arcurn 5y ago
Sure! Our model is focused on making sure that data gets encrypted before it hits our customers' infrastructure, so that there's nowhere on the backend where the data exists in plaintext. This isolates developers from misconfigura
14.
by arcurn 5y ago
Yep, but the binary running in the enclave has access to both the attestation document (including PCRs) directly from Nitro as well as a mechanism to fetch IAM policies and verify that they are from the genuine IAM server (verify the TLS CA
15.
by arcurn 5y ago
Yes! You might be thinking of node-secureworker[0]. We've been the maintainers for the last couple of years, but haven't been using it in production (concerns around Intel SGX) [0]: https://github.com/evervault&#x2
16.
by arcurn 5y ago
Yep, I think that makes sense. Certain use cases will have a need for some kind of on-prem/HSM approach, less from a practical perspective but more from a "doomsday modelling" perspective. Reminds me of the "nobody ever
17.
by arcurn 5y ago
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 usin
18.
by arcurn 5y ago
Thanks for commenting! One thing worth clarifying before diving into specifics is that Evervault doesn't store user data. We do store encryption keys, but the model is that our customers store encrypted data but not keys; Evervault sto
19.
by arcurn 5y ago
Hey Danny, I completely agree. Full end-to-end encryption is the ideal scenario. The biggest challenge is how we can bridge the gap between how companies build software today (very little, if any encryption) and how companies will build sof
20.
by arcurn 5y ago
Makes sense — the practical answer is: it doesn't. This is the eternal debate with TEEs. At some point, a company/fab/service provider has to be trusted to be acting in good faith. HSMs have existed for a very long time, and
21.
by arcurn 5y ago
> That sounds interesting. I'd like to test this hypothesis sometime ;) That sounds great! Feel free to shoot me an email on shane@evervault.com if you'd like to get further into the weeds :) Our main defence against invalid cu
22.
by arcurn 5y ago
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 cust
23.
by arcurn 5y ago
Hi there, our current root of trust is the AWS Nitro Security Chip. This means that if there was some kind of rogue supply chain within AWS' procurement + installation of these chips, the root of trust could be tampered with. We'v
24.
by arcurn 5y ago
Good point! We can safely isolate ourselves from any timing leaks by E3 because all E3 requests with potential timing leaks simply get transparently tunnelled to the end destination (e.g. an API you're passing through Relay), so a mali
25.
by arcurn 5y ago
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 infrastruc
26.
How we built the Evervault Encryption Engine (E3)(evervault.com)
81 points by arcurn 5y ago|42 comments
27.
by arcurn 5y ago
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 deta