"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.
I don't see anything objectionable in here. What do you take issue with? There's always an onus on customers to ensure that the service being provided will actually meets their needs.
Generally speaking, I agree with you in principle, but I think the aim here is to basically be able to escape a big lawsuit if a company uses them but screws up the implementation and doesn't follow directions, then faces a loss, then sues Evervault to get their money back. It's not Evervault's fault if you can't follow simple directions, in other words. It's also not their fault if you use them for 99% of things but your dev team just slips up and forgets to integrate some piece with Evervault at some point along the way, thus creating a vector for data leakage and/or attack. Can't fix stupid :-)
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.
Oh - fair enough. I tend to treat all marketing/advertizing copy as a (not even necessarily close) approximation of the actual specs, anyway, so the fact that the tagline isn't borne out by the actual implementation didn't even strike me as incongruous. But yes, you're right that those don't line up.
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.
I wonder how large is the submarket of developers aware of the need to encrypt data ... And also OK to bring a third party like evervault into the deal.
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.
Really appreciate the plain "how it works" section just below the fold on the homepage. So many security products offer fluffy marketing pages — it's clear what this does from an implementation perspective right away.
Yeah I would definitely be wary about this. A self-hosted option, even if not open sourced, seems like a no-brainer to me. Nothing wrong with providing it as a SaaS as well.
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.
Was thinking the same thing, there's a reason encryption and auth software is open source and run internally (like hashicorps Vault).
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.
Perhaps it's not as small as you think. It all depends on who is the adversary in your threat model.
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.
If someone has access to the physical device, that device need to be able to display the actual data = the device has the "secret" information already.
Yes I did mention that technique in my comment upthread. But there is a more simple stupid way: just perform the computation somewhere else, on some server you own, one some server you rent, on some service you rent... From the POV of the device in the field it doesn't really matter.
I don't know; I just read what's written on their home page:
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.
perhaps I misunderstood what that feature is; if that's true I suspect it's not entirely my fault, but there is something misleading in the product description.
I am founder & CEO of Skyflow PII data privacy vault. We are vaguely similar but our product line is focused on offering "PII database as a service" - and not really relays and cages. Happy to answer any questions.
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)
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 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!
If I can make a couple of suggestions for winning over that crowd.
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!
> we have carried out security audits with Cure53[0] and others
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.
> Encrypting cardholder data with Relay means that your system does not handle cardholder data, making Evervault your Cardholder Data Environment.
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.
Yes! We have a page coming soon, but Evervault is a QSA-audited service provider and we can reduce your PCI compliance scope to the simplest form (SAQ-A)
I had a bit of struggle to understand precisely how this works. I haven't had a need to use similar technology...But at least one mechanism seems to be:
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...
This looks pretty cool (particularly that it's easy to use). If you're already using AWS you could just use nitro enclaves to do this directly, but this makes it easier to use, and easier to use if you're not using AWS but trust AWS (+ evervault, particularly for availability). It's cool to see this for something other than just payment card info vaulting.
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.
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 plaintext data processing happens on Evervault's infrastructure, so our customers don't have any runtimes that handle sensitive data in plaintext.
> If someone has control of the application, aren't all bets off at that point?
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
Jumping in here to plug a company that I co-founded called Redact. We are developing a trustless way to store and process PII - our tech is end-to-end open source (unlike competitors), we don't use any proprietary encryption algorithms or techniques (unlike competitors), and we give users a way to control and monitor access to their own data. We think this is the future of Web3. Check out our website and I'd be more than happy to answer questions or provide some links to our source code if there's any interest.
https://redact.ws
Why does this website feel really familiar to me?
The styling makes me feel like it's a product of a company i've used before with exactly the same website, i thought maybe it was hashicorp but a quick look and thier styling isn't quite the same.
It is a common template ? Where else might i have seen it ?
Kinda feels like Parsec (https://parsec.app ), but honestly there are so many websites in that format these days...And yeah, this one even has a free tier and a paid tier, and a nice convenient "Pricing" link up top... Though to be clear, I'm not against valuable services getting paid; and this one at least makes it fairly clear what they _do_ on the front page...
A thought occurs to me: how would you envision this working for healthcare data governed under HIPAA? As you're probably aware, the requirement is to have PHI "encrypted at rest" and that I'm not supposed to share or transmit the data outside of my infrastructure or to that of partner companies who've signed a BAA.
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.)
Chiming in real quick to say: NICE! I really like how the home page gets right to the point of what it is and shows you a code sample, not a bunch of loosey-goosey executive-targeted buzzword copy written by an English major without a clue of what they're talking about or some GPT-generated garbage. It's fantastic that you guys get to the point of WHAT THE DAMN THING IS - and that makes me want to use it in the next project where this might be a good fit.
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!
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 inconsequential as they can possibly be.
This is a really nice implementation! Looks really simple to use. I think a lot of devs these days would love to not have to be responsible for sensitive data these days, especially with GDPR.
"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.