[hexedpackets]

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.

[1] https://en.wikipedia.org/wiki/Homomorphic_encryption

[bironran]

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.

[hexedpackets]

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