hexedpackets

> The compatibility with the AWS CLI was mostly excellent in my experiences.

Interesting, I've had the opposite experience. Every single AWS service I've ever tried to build tests around with LocalStack has run into compatibility issues. Usually something works in LocalStack but fails when it hits the real endpoint.

I guess the CLI itself has mostly worked, its more the LocalStack service not behaving the way the real service is documented/works.

That's a new regulation passed in December that doesn't take effect until April. At the moment, there is no cooling off period.

A cup of cauliflower is about 25 calories. A 2 pound head of cauliflower is 224 calories, only about 10% less than the burger.

We still need to add the format to our docs, but it's essentially:

prefix + base64(len_encode(metadata) + len_encode(key_tag) + aes_encrypt(data))

So definitely possible to decrypt it without JumpWire, if you have the keys. There are some pieces of metadata we add in that we could make optional if you want to reduce the resulting ciphertext size. That metadata adds a few extra bytes, but it doesn't grow with the data size.

Thanks, appreciate it!

It depends on the use case. In our experience, it's been rare that queries on PII need to do anything more complex than substring matching (which we're working on support for). We're definitely not trying to be able to encrypt every column, just to make some common workflows around PII and PHI a lot easier.

Custom views can help, but it does mean you're dealing with access controls directly in the database which can be hard to manage. And the database is fully exposed through backups or engineers with server access.

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).

Tonic is awesome! We think of synthetic data/differential privacy as a different use case - trying to replicate data across scoped environments while preserving certain properties or distributions of the entire data set. There is a security/privacy component from scrubbing the data, but the original data source is unmodified, and that's where we feel risk lies. And the desired outcome isn't to add security but to produce a data set that "looks like" the original well enough for testing/modeling/analytics.

> Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything?

Yep, that's exactly right. Application credentials are grouped under classifications, and policies can be included/excluded across classifications. We aren't passing authz through JumpWire but for something like Retool you can configure it to connect through different proxies for different users.

> I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?

Exactly. The engine which interacts with your data is almost always self-hosted, and the web app also can be if needed.

> At my scale (50 person company), it works reasonably well enough with just me maintaining it.

Makes sense! No reason to add more tools to your stack yet if the custom process isn't too burdensome.

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.