Ian Preston @ianopolous peergos.org Is your data secure?

Ian Preston @ianopolous peergos.org

Ian Preston @ianopolous peergos.org I want to store my files online, but without Dropbox being able to read them. I want to selectively share my photos, but without Facebook seeing them. I want to store my files online, but not in a company that could go bankrupt.

Ian Preston @ianopolous peergos.org What do I want? Security Convenience Control ● Safe login ● Strong crypto, ideally post-quantum ● Hide file metadata ● Web interface ● Log in from any device ● File syncing/mounting ● Publish files ● Resilient ● As convenient as Dropbox, Facebook ● Self hostable ● Selectively share files ● Hide contacts ● Pseudonymous ● Free of DNS ● Free of SSL CAs

Ian Preston @ianopolous Control ● Self hostable ● Selectively share files ● Hide contacts ● Pseudonymous

Ian Preston @ianopolous peergos.org Overall architecture IPFS Hash → data IPNS Public key → Hash PKI Server PKI root hash Follow requests Peergos Client Peergos Server

Ian Preston @ianopolous peergos.org Basic structure ● Global file system ● /username/yourfiles ● Tree of symmetric keys (TweetNaCl) with cryptographic links between (Cryptree) ● Location + Key = cryptographic access token or capability (CAP) ● Explicitly don't use convergent encryption!

Base key Directory File Metadata key Parent key Metadata key Sub-directory Parent key Metadata key ianopolous work File contents Parent key Base key Data key Cryptree peergos.org Ian Preston @ianopolous thesis.tex 72 KiB Modified: 15:23 14/3/2016 text/plain

Ian Preston @ianopolous peergos.org 5 MiB Chunk raw file 5 MiB 5 MiB 5 MiB 5 MiB Encrypt chunk 40 * 128 KiB Erasure code? 20 * 128 KiB Upload fragments Upload metadata IPFS Encrypted metadata + fragment hashes

Ian Preston @ianopolous peergos.org IPLD Structures WriterData Cid ownerPublicKey Optional generationAlgorithm Optional publicData <== CAP to public data Optional followRequestReceiver <== send follow requests Set ownedKeys to this key Map namedOwnedKeys Optional staticData <== encrypted CAPs Optional champ <=== file system is here!

Ian Preston @ianopolous peergos.org File CHAMP Map> Labels are 32 random bytes Keyset forms CRDT (grow only set with tombstones) Champ uses identity as hash Cryptree nodes themselves have merkle links to any encrypted fragments for the chunk Values can be made into file specific crdts (inside encryption) Links between different parts of same file or folder are encrypted => directory structure et al not visible to network (Compressed hash­array mapped trie)

Ian Preston @ianopolous peergos.org File CHAMP Cryptree node Champ node File fragment File fragment File fragment Champ node Champ node

Ian Preston @ianopolous peergos.org Decentralized write access? ● Cryptographically controlled with signing key pair (Ed25519) using IPNS ● Can grant other users write access by sharing this key ● Easy fine grained write access control

Ian Preston @ianopolous peergos.org How does sharing work? ● Users have a public boxing key ● To send a follow request: create a directory /myname/sharing/friendname ● Send a read CAP to this directory encrypted to friend's public key ● Shared files are currently vulnerable to a quantum computer ● Will move to post-quantum sharing as soon as a clear candidate arrives

Ian Preston @ianopolous Convenience ● Web interface ● Log in from any device ● File syncing ● Publish files ● Resilient

Ian Preston @ianopolous peergos.org Decentralized login? ● Only ever stored in RAM, never written to disk or transmitted Scrypt hash password username Root key Signing keypair Boxing keypair ~1 second

Ian Preston @ianopolous peergos.org Public links? ● read (or write) CAP encoded in a URL ● https:// demo.peergos.net/#Public_writing_Key/Subspace_label/Decryption_Key ● e.g. https:// demo.peergos.net/#2bBEyF99hKzU98M6y9H4scSXRza7xreaG7PcuydQKbfpp2DR5g4Y VavRsPw1T1u8qDzkA1pYXrs2KxBbFwQuDge6p1U/8gDZHdxtXXNLTghsUXqWtWUwSG VgjkqJhJYyUfrfMAJe/XpbvAJFoAK1hFNh3CLMgZSZvukLVoc794EXhh9YyGqjf ● Material after # is not sent to the server file still isn't exposed to the network → ● Can share an individual file or a folder

Ian Preston @ianopolous peergos.org Media players In browser viewers for: - video (also support streaming in browser using service workers) - images - audio - text - hex viewer Future: - sandboxed apps which we grant cryptographic capabilities - already have a prototype sandbox: browser + wine + x86 emulator cross compiled to JS – intercept the http requests and interpret as file requests in peergos

Ian Preston @ianopolous Security ● Safe login ● Strong crypto, ideally post-quantum ● Hide file metadata

Ian Preston @ianopolous peergos.org Can a login be cracked? ● Brute force is practically impossible with a good password ● Random 14 character alpha-numeric password has ~ 2^84 ~ 10^25 possibilities ● A GPU can calculate ~ 1M scrypt hashes/s (measured by litecoin users) ● One GPU cracking a single user’s login would take 10^19 seconds or ~ 300 billion years ● 300 million GPUs would take 1000 years ● GPU purchase cost = 300 billion USD

Ian Preston @ianopolous peergos.org

Ian Preston @ianopolous peergos.org What about quantum computer based attacks?

Ian Preston @ianopolous peergos.org ● All encryption is symmetric encryption using TweetNaCl, or hashing through scrypt ● Both have no known quantum attacks

Ian Preston @ianopolous peergos.org “But Javascript crypto is insecure!”

Ian Preston @ianopolous peergos.org Threat model A (The casual user): ● Trusts our public server ● Trust the SSL certificate hierarchy Depends on your threat model..

Ian Preston @ianopolous peergos.org Threat model B (The paranoid user): ● Doesn't trust our public server ● Doesn't trust the SSL chain Run Peergos on your machine AIR GAP Faraday cage Binary, compiled with 3 different compilers, from signed source

Ian Preston @ianopolous peergos.org Build security ● Reproducible builds, both server and front end (varies only on version of javac used) ● Do not use npm! Only 8 JS dependencies, all vendored (3 of which are crypto libraries) ● Have our own deterministic replacement for webpack, and minifiers ● Self host all assets ● Most of the client code is written in a type safe language (Java) and cross compiled to JS ● Will distribute updates through peergos itself

Ian Preston @ianopolous peergos.org Demo

Ian Preston @ianopolous peergos.org Current status: Pre alpha ● Web-interface – done ● Use actual IPNS - todo ● ● Fuse client – done ● Security audit – todo ● Granting write access – not in UI yet ● Private keystore of friends (TOFU) – done Tor integration – todo

Ian Preston @ianopolous peergos.org Join our community! Contribute https://github.com/peergos/peergos ● Sign up to hear when our alpha is ready (soon): https://peergos.org ● Try our demo at https://demo.peergos.net ● Read our book: https://peergos.github.io/book ● Currently we are a team of 4 contributors ●

Ian Preston @ianopolous peergos.org Questions?

Ian Preston @ianopolous peergos.org

Ian Preston @ianopolous peergos.org Peergos Dropbox OwnCloud SeaFile FreeNet Tahoe-LAFS Retroshare Open source Y N Y Y Y Y Y Self hostable Y N Y Y Y Y Y Data always encrypted at rest Y N N N Y Y N End to end encrypted (Client side encryption) including web browser Y N N N Y N (Gateway does the encryption) N Private keys never leave the client Y N N N Y N N/A Hides friendship graph Y N N N Y N/A Y Per file access control Y Y Y Y Y Y N Concept of file ownership + deletion Y Y Y Y N N Y Can create public links to files Y Y Y Y Y Y Y Can log in on multiple devices Y Y Y Y Y Y N Web interface Y Y Y Y Y N Quantum computer resistant encryption of non shared files Y N N N Y Y N Your files survive if your server self destructs planned N/A N N Y Y N Server written in a type safe language Y N N N Y N N Quantum computer resistant encryption of shared files planned N N N Y Y N Search planned Y Y Y N N Y Native directory sync planned Y Y Y N N Secure Chat planned N N N Y N Y Comparison