| >Group encryption: [...] Came here to ask just about that but I see it's on your roadmap already, that's good and godspeed with that since encryption is hard. During my PhD, I worked a little while with threshold encryption schemes (sometimes called horcrux encryption schemes, i.e. make n keys, you need at least m of them to perform some operations) (ref. my noob-ish question here ha https://crypto.stackexchange.com/questions/74763/is-there-an...). I created a small system that allowed one to reconstruct parametric data from 3D shapes, but if and only if you had at least n pieces of the whole model, because reasons. Reading this announcement, I recalled several things that came up during my research, which apply to this context as well. * How can one make sure that losing one key is not the end of the db (i.e. backup keys)? * How to share db access but not individual keys? (i.e. one key per user BUT all of them can read) * What if encryption is shared by n users but one of them loses their key? * How many keys for encrypting (or just one?), how many of them for decrypting? * Represent all of this in some sort of stateful model, after all it's a db (in my case it was files), it's meant to be cold storage, everything should to be able to be reconstructed/recovered from there. The list goes on and on ... Anyway, just wanted to say that this is a very interesting and promising feature to be found in a database. Great work, I'm eagerly waiting to get my hands on this. |
The basis we are exploring is using an algorithm called Signcryption (https://github.com/jedisct1/libsodium-signcryption) that is already included in pgsodium. This doesn't solve any of the shared private key issues you mention above, but it is a useful foundation for distributing encrypted messages that separate out sender and receiver identifiers from their keys, a sort of lower level foundation on top of which distributed key sharing can occur.
I also think signcryption is a great foundation for a better token format than JWT or PASETO, as it covers all of their use cases without algorithm confusion attacks (despite PASETO's insistence on "Algorithm Lucidity") and supports more features such as third party verification and streaming shared key generation from any token without having to exchange the key, we hope to use these tokens so that end-to-end peers can exchange tokens, derive streaming shared keys, and then do direct point-to-point message exchange using libsodium crypto_secretstream API which supports key ratcheting for forward secrecy.
Would love to discuss more about your research with you and include it with attribution into our future work, send me an intro at michel@supabase.io when any other ideas or resources you'd like us to see!