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:
- What cryptographic primitives can be used?
- How should read access be granted? For the entire oplog vs. for an individual entry.
- 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.
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?
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?
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?
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?
There are three considerations that could help answer this question:
Security Audits & Analysis
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.
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.