Transformations and Crypto

[Stebalien]

So, I'm putting this here for lack of a better place to put it...

When discussing IPLD, @jbenet brought up the concept of graph transformation programs. Basically, an IPLD object could point to to a portable/secure (e.g. compiled to webasm) program that could take the IPLD object as an input and could lazily generate some a different object as output. This would allow arbitrarily flexible abstractions (literally, turing complete). This is really useful.

However, @jbenet then noted that this could be used to add support for encrypting objects. That is, a decryption program could be written as a graph transformation that takes a key in addition to the object. After thinking about this, I realized that this isn't actually possible to do securely. In general, it's impossible to securely run untrusted code (even in a sandbox) on private data (cipertext/key). There will always be side channels by which that untrusted code can communicate with the outside world (at the end of the day, the user is a viable side channel).

I'm leaving this here as a not to future persons so nobody tries this. Basically, crypto, even decryption, must always be done by a small, carefully verified library.

[joeyh]

More generally, an IPLD object could include a functional program that takes other IPLD objects as additional inputs.

For example, an object that is a conflict-free replicated data type (CRDT) could have methods to modify its state (returning the new object), and a method to merge its state with a diverged replica.

Multiple such CRDTs could be composed to build up a larger IPLD object to implement a distributed system.

[Stebalien]

@joeyh Yep, that's the general idea. I just left this issue here as a warning to future implementers.