Evervault
evervault.com
evervault.com
"You provide User Data and Personal Data to Evervault with the understanding that any security measures we provide may not be appropriate or adequate for your business, and you agree to implement Security Controls (as defined below) and any additional controls that meet your specific requirements. In our sole discretion, we may take any action, including suspension of your Evervault Account, to maintain the integrity and security of the Services or Data, or to prevent harm to you, us, customers, or others. You waive any right to make a claim against us for losses you incur that may result from such actions. You are solely responsible for the security of any Data on your website, your servers, in your possession, or that you are otherwise authorised to access or handle."
Yeah, no. You either practice what you preach in your advertising or don't advertise what you won't commit to.
Promises like that, with liability waivers in the fine print, are always worthy of suspicion.
But yeah I see your point too - you don't go by "what I think they intend", what gets argued in court is the LETTER of the law, not necessarily its intent. Both sides have a point here.
As a sibling commenter said, though - it's not inherently suspicious that the company's covering their ass in the case of an incompetent user.
We'll do some work on improving this (probably removing the entire clause around waiving a right to claim) and ship the changes ASAP.
If you have applications that run in the field, and need to perform computation on data you don't want to be seized if the adversary gets hold of the device itself (state or private agents), then this may be a relatively low cost way to address this concern.
If you search for a solution for all possible threat models, well homomorphic encryption would all the boxes except it's too slow for doing anything practical with it.
There are scenarios where you can compute on encrypted data and produce a result that doesn't leak the entire data.
Evervault Cages
Process the data you encrypt with Relay or our SDK by deploying your code in Cages — isolated serverless functions hosted on Evervault.
Cages automatically decrypt your data in an isolated environment, so you can still process data without handling it in plaintext.
I believe what you're referring to is homomorphic encryption.
Is it easier to use than setting up a Vault cluster? Yes, without a doubt, so for building new things as a single developer, it definitely has a market.
It would be more difficult on larger businesses though, since they have internal processes & certifications, that now need to rely on a 3rd party.
Also being in the EU the first thing I look at is where the company is based and/or where they host my data, but I've trawled through this site and cannot seem to find a company address anywhere or details of their hosting setup? Nor is there a single "Security" page which outlines their credentials and security measures. I feel like these are critically important for a business like this which needs to build trust with potential customers.
The website design looks superb though and the product is definitely interesting.
EDIT: Ah noticed on the jobs page that they're in Ireland, but looks like their app front-end is hosted on Vercel and (per below) backend on AWS.
EDIT: And further confusion from the "Evervault Inc" in the footer and "Evervault Ltd" on Privacy Policy page. I'm not clear if this is an Irish company (and therefore covered by EU law) or a US company? These details are important for potential European customers.
Definitely still needs an exec summary "Security" page though with a callout to relevant blog articles if necessary.
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 encrypting all sensitive data is a no-brainer. Still early days here, but we're expending a lot of energy to make this happen.
Re: third-party dependency — we think the same way at Evervault. We bring third-party vendors into the mix if we think they can build something better than we could do ourselves, which is why we partnered with AWS on their Nitro Enclaves[0] product. Our root of trust is the AWS Nitro System. For customers who still aren't comfortable with us managing their security posture, we also offer on-prem and in-VPC options.
To answer your question: "market for encrypting data" is infinite but in reality that's not really a market since encryption is a concept and not really a product.
The markets that do exist are: * GDPR & CCPA compliance (think OneTrust) * Data Residency (think Cloudflare) * Data Security as a Service (think Okta/Auth0) * Customer Data Management (think CRM)
large enough to warrant a crypto-currency: https://build.scrt.network/The people making the decision to use a product like Evervault isn't always a technical/security audience, so it's a tricky balance to navigate. We want both engineers and non-engineers to understand why using Evervault is important, so sometimes we fall short. This feedback is much appreciated though, and we'll definitely keep it in mind next time we do a website revamp (soon!). Thank you!
1) As OP said, dial back "never" statements, there's no such thing as perfect security :)
2) When I look at a solution like this which essentially requires a lot of trust from customers (if your servers get hacked or your code is insecure, that's going to be a bit hit for your customers), I look for 3rd party validation. Something like a published 3rd party audit from a reputable consultancy, using good named consultants, with a clearly stated scope of work is likely to help allay fears about trusting a third party with a solution like this.
3) Talk some more about the experience of your team. What you're doing is hard to do well, so explaining where your team has experience of doing things like this in the past, will help.
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 suggestions which we will implement in our next website revamp. Thanks!
You need to be shouting about this on your new security summary page :)
It all builds a story of trustworthiness.
It seems like you have quite a lot of info captured in your blog, but the “blog” section is definitely not where I go first when I’m doing a quick scout of a company/service to size them up (from a “can I trust these guys?” perspective).
But I thought the point of the cages, is that _do_ decrypt the data. And any government mandated backdoors would then go into that process. You're not doing any homomorphic encryption here.
I guess my issue, is that you see both the keys and data, not just one.
(BYOK is an extremely important feature for this category.)
Does this mean Evervault is a PCI DSS service provider? Do you have an AOC yourselves and are you audited annually by a QSA? I had a quick look but couldn’t find PCI specifics on the site.
1. Data submitted by end user
2. Intercepted by an Evervault Server and encrypted
3. Hits my Application where I utilize the encrypted data without being able to see it
4. Submit it to some other service (Twilio say)
5. Relay intercepts request and decrypts required fields before data is sent on to Twilio.
6. Presumably response from Twilio is also encrypted? Or it's optional?
I'd be interested to hear from anybody who has implemented these kinds of flows to better understand uses cases and the complications etc...
(There's some nuance around re-encryption proxies and how that is handled.)
Biggest problem I could see with applications is that if you were using this inside a larger application, someone with control of the application could just change the less-secure application to bypass Evervault entirely. Wouldn't compromise historical/data-at-rest data already inside evervault, but would bypass it for new submissions. That doesn't mean this isn't useful, but it would be a concern in some use cases.
At some point, your application has to decrypt the data to work with it. The person with control of the application would exfiltrate data that way.
All plaintext data processing happens on Evervault's infrastructure, so our customers don't have any runtimes that handle sensitive data in plaintext.
Great point, but not necessarily. This is what we are trying to solve with Redact. Would be interested to hear your thoughts on our solution: https://redact.ws
Some more details here: https://old.reddit.com/r/rust/comments/q79grm/redact_tool_fo...
It is a common template ? Where else might i have seen it ?
My understanding of the regulatory parts of the law here is probably flawed in some way, so I apologize for that in advance, but could you go into a little detail about how that might work from a business-to-business/contracts standpoint? Like, do you guys sign BAAs at all, or are you outright going to be refusing healthcare related business/processing of PHI for some reason?
(Either answer is fine, I just want to know if this is a decent fit for HIPAA-governed data, that's all.)
Bookmarked in Raindrop for future reference. Next time I need to encrypt data in an app, I'll see if this is a good fit. Thanks for sharing!