From 92b789e7fc5d21daa311d9ba155b9ee34337ce68 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Sat, 29 Feb 2020 20:43:17 -0800 Subject: [PATCH 1/4] Add draft of peergos protocol overview --- protocols/peergos.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 protocols/peergos.md diff --git a/protocols/peergos.md b/protocols/peergos.md new file mode 100644 index 0000000..d51f944 --- /dev/null +++ b/protocols/peergos.md @@ -0,0 +1,17 @@ +# Peergos + +Peergos is an e2e encrypted distributed file storage service. At the base layer, files are stored using IPFS. + +### Identity + +There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. (how is consensus guaranteed?) + +### Data storage + +Each user must have at least one peergos server. The servers run an instance of IPFS. Data is content-addressed: stored in mappings from hash to hashed data. + +The user lists the IPFS node id of the server (hash of its public key). It synchronizes their writes and displays the latest root hashes. Data is always encrypted on the servers. + +### Social + +Users can follow each other. Follow requests are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. From 53f7484c41a15014ac7f0a9970c1b0d0573b5f04 Mon Sep 17 00:00:00 2001 From: Jay Graber Date: Thu, 5 Mar 2020 19:25:53 -0800 Subject: [PATCH 2/4] Add to draft --- protocols/peergos.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/protocols/peergos.md b/protocols/peergos.md index d51f944..dbb80bc 100644 --- a/protocols/peergos.md +++ b/protocols/peergos.md @@ -4,7 +4,9 @@ Peergos is an e2e encrypted distributed file storage service. At the base layer, ### Identity -There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. (how is consensus guaranteed?) +There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. (how is consensus guaranteed? Is the corenode same as the peergos nodes?) + +Login and key management: A peergos user's private keys are derived every time log in using their username and password. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. ### Data storage @@ -15,3 +17,19 @@ The user lists the IPFS node id of the server (hash of its public key). It synch ### Social Users can follow each other. Follow requests are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. + +### Privacy and Access Control + +Files are encrypted on the peergos nodes, which only have access to metadata. + +Access to files gained through social follows can be revoked by rotating cryptographic keys. + +Access is controlled through cryptographic capabilities: + +- the file owner's public signing key is used to look up the filesystem +- the label is used to look up the file +- after retrieval, it is decrypted using the base key given to the person who has access + +A user can publish a capability of a file or folder they control which makes it publicly visible. + +A user can also share links to files, like a google doc "share" link, which lets anyone who views it at that special URL to view the file. However, the file is not transmitted unencrypted over the network, as the key to decrypt it is in the URL itself, and is interpreted locally in the browser. From b5e7d04cecb5dc75a69d638e7bed570ae8bbf50e Mon Sep 17 00:00:00 2001 From: Ian Preston Date: Mon, 27 Apr 2020 07:31:11 +0000 Subject: [PATCH 3/4] Update Peergos information --- protocols/peergos.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/protocols/peergos.md b/protocols/peergos.md index dbb80bc..a7a5bc4 100644 --- a/protocols/peergos.md +++ b/protocols/peergos.md @@ -1,18 +1,18 @@ # Peergos -Peergos is an e2e encrypted distributed file storage service. At the base layer, files are stored using IPFS. +Peergos is an e2e encrypted storage, social and application protocol and platform. It is built on top of IPFS. More information is available in their [book](https://book.peergos.org) or their [source](https://github.com/peergos/peergos). ### Identity -There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. (how is consensus guaranteed? Is the corenode same as the peergos nodes?) +There is a global append-only log for the public key to username mappings. This is mirrored on every node in the peergos system. Names are taken on a first come first served basis. Consensus is currently a single server, but long term this would make sense to put into a stripped down blockchain for more decentralization. -Login and key management: A peergos user's private keys are derived every time log in using their username and password. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. +Login and key management: A peergos user's private keys are derived every time they log in using their username, password and a published salt. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. Users store their friends keys in their encrypted storage space in a TOFU keystore. Users can verify key of friends in person or over the phone using QR codes or fingerprints. ### Data storage -Each user must have at least one peergos server. The servers run an instance of IPFS. Data is content-addressed: stored in mappings from hash to hashed data. +Each user must have at least one peergos server. The servers run an instance of IPFS. Data is content-addressed: stored in mappings from hash to data. During upload the client splits files into 5 MiB chunks which are each independently encrypted (along with encrypted metadata) and stored in a merkle-CHAMP (compressed hash array mapped prefix trie) in ipfs. Directories can't be distinguished from small files, nor are the sizes of files, or the number of files, or directory structure, or who has access to them visible to the server. -The user lists the IPFS node id of the server (hash of its public key). It synchronizes their writes and displays the latest root hashes. Data is always encrypted on the servers. +The user lists the IPFS node id of the server (hash of its public key). It synchronizes their writes and displays the latest root hashes. Data is always encrypted on the servers. The servers are in fact trustless - in that they don't have access to any sensitive information, and clients don't rely on them for authenticity or privacy. Furthermore, the servers don't trust IPFS, or the data store (which can be further removed, e.g. S3). ### Social @@ -20,16 +20,15 @@ Users can follow each other. Follow requests are sent through a user’s storage ### Privacy and Access Control -Files are encrypted on the peergos nodes, which only have access to metadata. +All encryption happens on the client, which might be a native peergos client, or just a browser. The Peergos nodes (the servers) don't have access to any metadata. -Access to files gained through social follows can be revoked by rotating cryptographic keys. +Access to files gained through social follows can be revoked by rotating cryptographic keys. Access is hierarchical, and stored in an encrypted structure call [cryptree](https://book.peergos.org/security/cryptree.html). -Access is controlled through cryptographic capabilities: +Access is controlled through cryptographic capabilities. A read-only capability consists of the hash of the public key of the owner of the file, the writer of the file, a random label, and a symmetric encryption key: +(owner hash, writer hash, 32 byte random label, 32 byte symmetric key) -- the file owner's public signing key is used to look up the filesystem -- the label is used to look up the file -- after retrieval, it is decrypted using the base key given to the person who has access +A writable capability additionally includes the privat eky corresponding to the writer key, which is used to sign updates. A user can publish a capability of a file or folder they control which makes it publicly visible. -A user can also share links to files, like a google doc "share" link, which lets anyone who views it at that special URL to view the file. However, the file is not transmitted unencrypted over the network, as the key to decrypt it is in the URL itself, and is interpreted locally in the browser. +A user can also share secret links to files, like a google doc "share" link, which lets anyone who views it view the file. These secret links still don't expose the file to the server. The file is not transmitted unencrypted over the network, as the key to decrypt it is in the URL itself, and is interpreted locally in the browser. From be4080fdd25a90a2097397ede6dd609b0b955352 Mon Sep 17 00:00:00 2001 From: Ian Preston Date: Mon, 27 Apr 2020 07:34:35 +0000 Subject: [PATCH 4/4] More Peergos update --- protocols/peergos.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/protocols/peergos.md b/protocols/peergos.md index a7a5bc4..fe11788 100644 --- a/protocols/peergos.md +++ b/protocols/peergos.md @@ -8,6 +8,8 @@ There is a global append-only log for the public key to username mappings. This Login and key management: A peergos user's private keys are derived every time they log in using their username, password and a published salt. Specifically, a signing keypair, boxing keypair, and symmetric key is derived. Users store their friends keys in their encrypted storage space in a TOFU keystore. Users can verify key of friends in person or over the phone using QR codes or fingerprints. +This enables multiple device support, and no awkward key management UX. The user never needs to see a key or a hash. + ### Data storage Each user must have at least one peergos server. The servers run an instance of IPFS. Data is content-addressed: stored in mappings from hash to data. During upload the client splits files into 5 MiB chunks which are each independently encrypted (along with encrypted metadata) and stored in a merkle-CHAMP (compressed hash array mapped prefix trie) in ipfs. Directories can't be distinguished from small files, nor are the sizes of files, or the number of files, or directory structure, or who has access to them visible to the server. @@ -16,7 +18,7 @@ The user lists the IPFS node id of the server (hash of its public key). It synch ### Social -Users can follow each other. Follow requests are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. +Users can follow each other. Follow requests are sent through a user’s storage server, which is contacted via its public key. Follows are one-way, and allow sharing files and sending messages. Critically, the server never sees who is following who (even follow requests are blinded). You store your own social graph encrypted in your peergos space. ### Privacy and Access Control