You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: