Database Encryption & Read Protection

Disscussion for: Database Encryption Project.

Let me give a brief summary of the project, the current state of the discussion gathered from #819 and an SCP proposal I produced a few months back.

What happened until now?

OrbitDB Stores are publicly readable. And initially the OrbitDB development was not focused on the issue of private stores, though ACLs were implemented with a mind towards the future possibility of Read Access Control.

Why use encryption?

Because OrbitDB stores manifest and oplog on IPFS and uses IPFS PubSub for communication, which can both be accessed by anyone in the IPFS Network with low enough latency, encryption is the only method known to implement read access control.

What problems exist for implementing encryption?

In order to define Read AC in a specification, I think a few questions need to be answered. (Gathered from #819 and my own considerations)

What security guarantees should encryption give to the user?

What security guarantees does OrbitDB Encryption give the users?

To be secure, OrbitDB must have properly defined security guarantees for it's users to rely on and that can be verified by independent parties.

What Library to use?

How will crypto libraries be supplied by the user?

No standard crypto library has been choosen. It should be left to the user to choose the library that is most secure according to their research.

OrbitDB has to provide an API for injecting such libraries into OrbitDB encryption.

What should be encrypted?

Should the entire oplog or only the entries be encrypted?

• Encrypt only the payload of the entries. Leaving the structure of the oplog for all to see.
• Encrypt the entire oplog including the meta data inside the entries. The structure of the oplog would thus be hidden.

Tangentially related to this question is the question of hiding (i.e. encrypting or hashing) the manifest and the PubSub channel name and communication.

How should encryption work?

What scheme will OrbitDB use for Encryption and granting read access?

There are three considerations that could help answer this question:

1. What cryptographic primitives can be used?
2. How should read access be granted? For the entire oplog vs. for an individual entry.
3. How many keys should be handled and how? What should the key store look like?

Security Audits & Analysis

How will it be ensured that OrbitDB Encryption is secure?

Next steps would in my opinion be to define an SCP for OrbitDB Encryption followed by a reference implementation.

That implementation and SCP should then be verified based on the security guarantees given by OrbitDB to ensure no bugs or errors in the protocol remove the security guarantees.

• Will Audits be conducted before releasing encryption on OrbitDB?
• And who will be responsible for vulnerabilities, exploits and mitigations in the future after encryption has been released to OrbitDB?

Should this be part of OrbitDB 1.0 or rather a later release?

This is a very large project and I don't yet see how this can be implemented in a timely fashion along side those many other projects for 1.0. Maybe Encryption should be scheduled for a later release of OrbitDB 1.x?

I would like to ask for feedback to this issue from @tabcat @aphelionz @haadcode as well as anyone else who has been discussing and thinking about this project and possible feature.