Open ianopolous opened 3 years ago
Some technical infos:
I must say the documentation explains very clearly the threat model of Peergos.
It may indeed fit in both File Sync and File Sharing, although I think File Sync would be a better fit, but it has several features dedicated specifically for secure file sharing (especially private group file sharing, which is not something that I've seen much in other open-source E2EE softwares, so this may be an argument to also add it in file sharing as a Worth Mentioning).
Note that with the Pro plan (50GB E2EE storage and office apps and media streaming for 5 GBP/month), Peergos may also be a candidate for Cloud storage providers, but I'll leave that to someone else who worked on this section to compare with current offerings :-)
@ianopolous thank you very much for developing this software, it's very interesting!
I've got some questions for you:
Unlike other products out there Peergos protects your social graph as well. Your contact list is not visible to the server and is stored encrypted in your own space. Furthermore, if a user shares a file with another user, the server can't deduce this relationship. A Peergos server doesn't store any sensitive data or metadata.
How can this be possible? Assuming both users connect to the same server, I can imagine the server can monitor (using an in-house software, as it seems clear that you did not implement any such logging function in Peergos) who is sharing data with whom, or at least who is downloading from whom, no? Furthermore, I guess IP addresses are not hidden, right?
@lrq3000 Thank you for your feedback and questions. I'll try to answer everything here. Do let me know if anything is unclear or you have more questions.
Currently we have only implemented local disk or S3 compatible storage layers. The concept of a file doesn't exist by the time encrypted data hits the storage layer. Each file is split into 5 MiB chunks which are independently encrypted and stored in a merkle-champ (compressed hash array mapped prefix-trie) data structure in IPFS. This merkle-champ is a map from random label to encrypted chunk. Different chunks of the same file are not linkable, and directories are indistinguishable from small files in the champ. Our threat model assumes everything in IPFS is public. File chunks and directories are also padded to a multiple of 4 KiB before encryption to obfuscate exact size (leaving only 1280 possible chunk sizes in the entire system). All file meta-data including names, properties, thumbnails, etc. are encrypted client-side (and also padded to protect filename length et al).
We go to great lengths to protect social metadata on the API level. No API call explicitly links two users. When one user sends a follow request to another user, the request in blinded, similar to what Signal does, before sending - so the server can only see the target of the request. There also isn't a concept of logging in from the server's perspective, so it can't say that a given request came from a certain logged in user. Between different servers the plan is to implement onion routing on the p2p stream level in IPFS, but that hasn't happened yet.
A user's contact list is stored encrypted in their own Peergos space. This is essentially a TOFU keystore of their friends' usernames and public key chains. These keys can also be verified in person using a QR code and the same algorithm that Signal uses.
When a user shares a file, all they are doing is actually modifying a file in their own space, which the recipient already has a capability to from the initial follow request when they became friends/followers. So if a server were maliciously logging IP addresses in this case they can't link the act of file sharing because the sharer is just modifying their own files.
Downloading shared files is similar. The recipient's calls to retrieve blocks owned by the sharer are not attached to any login or session. Nothing is perfect though, and a malicious server could attempt to do timing based attacks or correlate IP addresses just as Signal can. The only sure defence in this case is to run your own server and wait for onion routing to be implemented.
Basic Information
Name: Peergos Category: Private storage, sharing, social and application platform URL: Main site: https://peergos.org URL: Whitepaper: https://book.peergos.org URL: Source: https://github.com/peergos/peergos
Description
A group of us have been working on Peergos since 2013, initially in our spare time and mostly for free, though we are aiming for a sustainable business model based on subscription for a hosted version. We strongly believe that the human right to privacy should be easy for anyone to exercise online. Our end goal is a privacy focused web, that works in existing browsers and protects ordinary people.
Right now, Peergos is an open source, peer-to-peer end-to-end encrypted storage, social and application protocol/platform. Its core is a global filesystem with identity controlled by the end-user and fine grained server-less access control. You can share things with friends on Peergos or via a secret link with anyone. We're building more applications on Peergos but we already have the following:
We support huge files - even streaming large videos in the browser (via service workers and writable streams), or downloading multi-gigabyte files direct to the filesystem.
A Peergos server is untrusted - clients verify everything they receive You can log in through any Peergos server. We go to great lengths to protect metadata (even from the server) including the following:
One of our 3 key criteria is convenience. That means an average non-technical user should be able to easily use it safely and securely. This has consequences: e.g. the user should never have to see a cryptographic key or hash, sharing should be a few clicks.
I'm very happy to answer any questions here.
Why I am making the suggestion
We have entered beta now and have been running in production for almost two years. We think a lot of people could benefit from using Peergos.
My connection with the software
I am a co-founder and project lead.