Skip to content
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.

CRDT: identify authorship #12

Open
pgte opened this issue Jan 24, 2018 · 4 comments
Open

CRDT: identify authorship #12

pgte opened this issue Jan 24, 2018 · 4 comments

Comments

@pgte
Copy link
Contributor

pgte commented Jan 24, 2018

When a peer creates a DAG node, contain enough information that allows other peers to verify the authorship.

@pgte
Copy link
Contributor Author

pgte commented Jan 24, 2018

related: authenticating DAG node authorship.

@pgte pgte added this to the 2018Q1 milestone Jan 24, 2018
@fritzy
Copy link

fritzy commented Feb 26, 2018

I'm going to see if I can make a y.js datatype that is signed and verified.

@dmonad
Copy link

dmonad commented Feb 27, 2018

Hey @fritzy

You could do this on the type level. But I think it makes more sense if we would encrypt all messages that are exchanged between the users. This way we have a bit of entropy in the encrypted messages. Also we don't want attackers to deduce content from the document structure.

A simple approach would be to use AES encryption and share the secret with the users that are allowed to edit the note. But this does not allow read-only users..

A more interesting idea would be to use a mechanism where a read-write-key is used to create document updates. And a read-only key is used to decrypt document updates. This is pretty much publc key cryptography. But in this case we would use the private key to encrypt messages, and a public key to decrypt messages. I don't have a lot of experience in cryptography and I have no idea if the above approach is secure at all.

The problem is that we have lots of small document updates. So it is probably easy to compute the private key if a certain amount of messages are created.. Also we should probably also have a look at how OTR and the signal protocol works.

@pgte pgte added the to do label Apr 3, 2018
@pgte pgte modified the milestones: 2018Q1, 2018Q2 Apr 4, 2018
@fritzy
Copy link

fritzy commented May 9, 2018

Encryption and ACL is a separate issue from authorship (authentication vs. authorization).

All DAG entries should be signed by a session key of the author. The session key refers to a Decentralized Identifier that contains the public session key https://w3c-ccg.github.io/did-spec/ and is attested by an identity service which provides a proof of identity. https://hackmd.io/s/H17TwVqsz#

When you read a DAG node, your client will check the signature by looking up the DID and proof from the identity service. This will prove authorship.

If the payload needs to be encrypted, then it will be done so along with the signature at another layer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants