Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Peergos Architecture

Ian Preston
July 10, 2018

Peergos Architecture

An introduction to Peergos

Ian Preston

July 10, 2018
Tweet

More Decks by Ian Preston

Other Decks in Science

Transcript

  1. 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.
  2. 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
  3. 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
  4. 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!
  5. 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
  6. 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
  7. Ian Preston @ianopolous peergos.org IPLD Structures WriterData Cid ownerPublicKey Optional<UserGenerationAlgorithm>

    generationAlgorithm Optional<FilePointer> publicData <== CAP to public data Optional<Cid> followRequestReceiver <== send follow requests Set<Cid> ownedKeys to this key Map<String, Cid> namedOwnedKeys Optional<UserStaticData> staticData <== encrypted CAPs Optional<Cid> champ <=== file system is here!
  8. Ian Preston @ianopolous peergos.org File CHAMP Map<Label, Cid<Cryptree node>> 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)
  9. Ian Preston @ianopolous peergos.org File CHAMP Cryptree node Champ node

    File fragment File fragment File fragment Champ node Champ node
  10. 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
  11. 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
  12. Ian Preston @ianopolous Convenience • Web interface • Log in

    from any device • File syncing • Publish files • Resilient
  13. 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
  14. 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
  15. 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
  16. Ian Preston @ianopolous Security • Safe login • Strong crypto,

    ideally post-quantum • Hide file metadata
  17. 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
  18. Ian Preston @ianopolous peergos.org • All encryption is symmetric encryption

    using TweetNaCl, or hashing through scrypt • Both have no known quantum attacks
  19. 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..
  20. 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
  21. 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
  22. 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
  23. 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 •
  24. 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