Congrats on the launch! This sounds pretty cool.
Did you have to get into the weeds of the wire protocols that Postgres/Mysql use? What was that like?
Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
11–20 of 80 posts
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#12amazing! we've been looking for smth like this! just registered via website
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#13FYI, I think there may be a typo on your `https://jumpwire.ai/pricing` page on the `How are keys handled?`
``` How are keys handled? We generate unqique encryption keys for every account and store them in a secure secrets manager. Subkeys are routinely created and rotated from the master key. For additional security, we support user provided keys on our Team and Enterprise plan. ```
`unqique` --> `unique`
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#14How did you solve range queries? Prefix/suffix queries? Index performance? Aggregation on database end?
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.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#15Congrats on the launch! This sounds pretty cool. Did you have to get into the weeds of the wire protocols that Postgres/Mysql use? What was that like?
Indeed we did get into the weeds. PostgreSQL was fairly straightforward, MySQL was a big challenge. Interestingly the hard parts are supporting the large variety of authentication handshakes that MySQL/Maria supports, not the queries themselves. This is the fun part of our job! ;)
Also critical is ensuring encryption occurs within the database transaction, so that data doesn't leak into write-ahead logs or change data capture streams. Since we manage keys/rotation this takes some careful logic in our engine.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#16FYI, I think there may be a typo on your ` https://jumpwire.ai/pricing ` page on the `How are keys handled?` ``` How are keys handled? We generate unqique encryption keys for every account and store them in a secure secrets manager. Subkeys are routinely created and rotated from the master key. For additional security, we support user provided keys on our Team and Enterprise plan. ``` `unqique` --> `unique`
Thanks for letting us know, should be fixed in a minute!
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#17What's the risk to your business of other data security companies (like BigID) offering this kind of functionality?
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#18Congrats on the launch! Interesting product.
How are updates handled, if I’m hosting the container in my cloud? How should I plan for troubleshooting if there are incidents involving JumpWire?
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#19Nice! I've been using a plugin [1] for Prisma that does something similar, but this sounds much more comprehensive.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#20So if the fields are encrypted by the proxy on the way to the DB, how do queries and indices work since it would be pretty much invisible to the DB and the query planner? Thanks! I really like the approach you are taking since it could be a quick drop-in deployment that solves a huge problem for us.
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.