🆕 Software Suggestion | Peergos

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:

photo gallery
video and audio players
text and markdown editor
PDF viewer
planning boards (kanbans)
calendar
social feed
private profiles
easy web hosting directly from Peergos (no servers, DNS or TLS certificates required)

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:

file properties (name, modification time, mimetype etc.)
file size
whether something is a directory or file
who or how many people have access to a given file
directory structure
your social graph

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.

[X] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

Some technical infos:

Peergos was independently audited by Cure53.
All files and data are client-side encrypted and even the relationship between users sharing files: "The underlying encryption uses Tweetnacl for both symmetric and asymmetric encryption. This means files are encrypted with xsalsa20-poly1305, data is signed with Ed25529, and shared keys are exchanged using Curve25519. [...] Peergos protects your metadata as well as your data. Everything from file and directory names, sizes and other properties are encrypted or obfuscated. 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. We take your privacy seriously!"
Trustless servers: "Your Peergos server doesn't store or have access to any unencrypted sensistive information. This means that even if the server is breached, the attacker cannot read your data without a further active attack on users by delivering a malicious web client to those using the web interface."
Fully open-source and self-hostable. Note that the free hosting plan includes only 200 MB, which is understandable given how the project is (under-)funded. So for privacy conscious folks, self-hosting is a great solution.

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:

If I understand correctly how Peergos works, it's essentially a wrapper over a file storage medium (can be a cloud storage, Amazon S3, dropbox, local disk, anything) and it creates a IPFS handle when sharing the files with others (but hence no IPFS ID is created for non-shared files? Or they are created anyway for every uploaded files? Because if the latter, then there's no way to upload private files, since IPFS IDs are public AFAIK?). The files are then shared P2P between devices who still have a copy of the files. All data and files meta-data is encrypted client-side. Is that a correct description of how Peergos works?
Next I would like to know more about your security features to hide the social network:

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.

privacytools / privacytools.io