A manual rotation is one click on the web page, and we can automatically rotate on a schedule to limit the scope of a compromise if a key gets leaked. Full rekeying is Coming Soon™ - fields encrypted with JumpWire have some metadata about which key is used which makes it easier to find rows that need to be re-encrypted, but the end to end process isn't launched yet.
Thanks! Some databases have encryption support but it is either coarse (row-level encryption is offered in a few databases for example) or it's a low level construct that becomes really complex to integrate - especially if you want to seamlessly decrypt some data. They're often only available in enterprise versions (MongoDB and MySQL do this).
pgcrypto mentioned below is a good example. It's a great extension that works really well, and if you're only using PostgrSQL you could build a lot of the functionality of JumpWire using it. But it requires a lot of engineering work to fit into your application. Having the basic encryption functions only gets you part of the way to a full solution - the rest is aligning those with high level policies and keeping up to date as data schemas change.
Yeah, the mix of permissions can definitely be a big pain. We're building with that in mind - policy exceptions can be set so that specific groups of applications get the raw data when querying. All of the policies stack too; one common setup is to encrypt by default, then allow some specific tool to get raw data but audit the queries it's doing.
I guess but yeah usually the hot databases will be encrypted. When moving to the data lake / warehouse its all unencrypted. I think it really comes down to What kind of data you're working with.
Last Password was hacked twice this year. How many data breaches are there on a regular basis. The reality is the cost of trouble worth the possibility. As much as everyone wants to say they care about users data, the reality in most companies is very different.
Our engine is self-hosted, so all of the data is kept local to your network and we can't read any of it. Concerns about data access and query latency are the two biggest reasons we decided to take the self-hosted approach.
Whether engineers can access the keys and decrypt data depends on your setup. The engine can use either AWS KMS or Vault for top-level key management, so if an engineer has full permissions over those then they could get the keys out. We can also host the keys in our infrastructure and sync them over to the engine if you're comfortable with that tradeoff.
Thanks! The plugin is pretty nice if you're sticking to just Prisma for your backends. Always happy to chat about your use case or give a demo of how JumpWire compares if you're interested.
Glad to hear you like our approach! We haven't fully solved indexing/complex querying yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. When encrypting directly in the database most queries other than direct comparison won't work. We have some early work started on using both homomorphic encryption [1] and format-preserving masking which opens up the ability to use other query operations.
With JIT response encryption none of that is an issue, the database still has the raw data but applications are protected. The downside is it can be slow for large amounts of data.
The short answer is we haven't fully solved it yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. For the former most queries other than direct comparison won't work - we have some early work started on using both homomorphic encryption [1] and format-preserving masking to help there.
With JIT response encryption none of that is an issue, but it can be slow for large amounts of data. Any kind of big-data analytics will be a poor fit for JumpWire right now.
yeah, FHE isn't, yet, something that can be used in a busy production env. At best I'd say it's a specialized tool, though in my mind it's a toy solution - can work for n=1, possibly for n<(low numbers) but not for large N.
Totally agree. We're likely going to implement a partially homomorphic solution that allows for some specific queries. We aren't trying to build a general purpose computational environment as the use cases we support don't require arbitrary computation. The data people encrypt with JumpWire is pretty much all strings and the queries on them are mainly doing some sort of substring matching (mainly prefix/suffix).
The value prop is definitely very similar. I'm not as familiar with Voltage as I am with other solutions, but my understanding is that it requires either using the Voltage database driver (JDBC/ODBC in particular) or an HTTP API.
With JumpWire, all of the works happens in an engine proxy that works directly with the database protocols. That makes the integration simpler - any language and connector can be used by just changing the hostname and auth. The downside is it's harder for us to add new databases - Voltage's approach definitely wins out there.
We have thought about that! It's a nice approach for some use cases but having just a read-only copy ends up being pretty limiting. Often people using internal tools (particularly customer success) needs to modify some fields in a record but shouldn't have unrestricted access to everything. We've found that being able to protect specific fields instead of the entire database gives a lot more flexibility.
