search

orbitdb-archive / ipfs-log

Append-only log CRDT on IPFS
https://orbitdb.github.io/ipfs-log/
MIT License
398 stars 55 forks source link

Payload Encryption Support #191

Open zachferland opened 5 years ago

zachferland commented 5 years ago

It appears that with the identity provider now it would be easier to support/implement payload encryption by adding optional encrypt/decrypt to to the identity provider as well. Any more thoughts on this? and/or is this part of a larger access control conversation?

Would be interested in implementing, we currently implement a orbitdb store that wraps 'orbit-db-kvstore' and encrypts/decrypts values, but would be nice to encrypt entire payload at log layer.

TheFrozenFire commented 1 year ago

I'm implementing encrypted messaging for orbitdb, and I'm interested to know if anyone can suggest improvements to my approach. Really, what I'm doing is adding encryption to ipfs-log, based on diffie hellman key exchanges to some set of target keys.

There will exist some strategy for determining which public keys to use, determined by the application (e.g. published in the OrbitDB manifest). For instance, the manifest could specify a set of static public keys + some curve, or the keys could be determined by the access controller ("read access"), or the keys could be recovered from the written messages if no "read keys" are configured, etc.

Each entry's payload will be encoded (CBOR/JSON/etc) into a stream. Then, an AES key will be produced and used to encrypt that stream. For each "read key", a DH exchange will be produced in order to generate a per-read-key AES key, which will itself be used to encrypt the message AES key, and then the map of "read key" to encrypted message key will be included in the entry to be broadcast to peers.

From this mapping, a given peer who knows a valid read key can find their encrypted message key, perform a DH between the read key and message PK (also determined by some strategy such as recovering the PK of the identity that signed the entry). This DH-derived key can be used to decrypt the message key, to then decrypt the payload.

I have already implemented this scheme in an application-specific manner, and it works wonderfully. I'm actively working on making it generic, so that any OrbitDB store can use the encrypted log implementation.