removed PGP

docs/onionr-draft.md

@@ -1,72 +1,49 @@
-# Onionr Protocol Spec
+# Onionr Protocol Spec v2
 
-A social network/microblogging platform for Tor & I2P
-
-Draft Dec 25 2017
+A P2P platform for Tor & I2P
 
 # Overview
 
 Onionr is an encrypted microblogging & mailing system designed in the spirit of Twitter.
 There are no central servers and all traffic is peer to peer by default (routed via Tor or I2P).
-User IDs are simply Tor onion service/I2P host id + PGP fingerprint.
-Clients consolidate feeds from peers into 1 “timeline” using RSS format.
-Private messages are only accessible by the intended peer based on the PGP id.
-Onionr is not intended to be a replacement for Ricochet, OnionShare, or Briar.
-All traffic is over onion/I2P because if only some was, then that would make that traffic inherently suspicious.
+User IDs are simply Tor onion service/I2P host id + Ed25519 key fingerprint.
+Private blocks are only able to be read by the intended peer.
+All traffic is over Tor/I2P, connecting only to Tor onion and I2P hidden services.
+
 ## Goals:
-    • Selective sharing of information with friends & public
+    • Selective sharing of information
     • Secure & semi-anonymous direct messaging
     • Forward secrecy
     • Defense in depth
-    • Data should be secure for years to come, quantum safe (though not necessarily every “layer”)
+    • Data should be secure for years to come
     • Decentralization
     * Avoid browser-based exploits that plague similar software
     * Avoid timing attacks & unexpected metadata leaks
-## Assumptions:
-    • Tor & I2P’s transport protocols & AES-256 are not broken, sha3-512 2nd preimage attacks will remain infeasible indefinitely
-    • All traffic is logged indefinitely by powerful adversaries
+
 ## Protocol
-Clients MUST use HTTP(s) to communicate with one another to maintain compatibility cross platform. HTTPS is recommended, but HTTP is acceptable because Tor & I2P provide transport layer security.
+
+Onionr nodes use HTTP (over Tor/I2P) to exchange keys, metadata, and blocks. Blocks are identified by their sha3_256 hash. Nodes sync a table of blocks hashes and attempt to download blocks they do not yet have from random peers.
+
 ## Connections
-    When a node first comes online, it attempts to bootstrap using a default list provided by a client.
-    When two peers connect, they exchange PGP public keys and then generate a shared AES-SHA3-512 HMAC token. These keys are stored in a peer database until expiry.
-    HMAC tokens are regenerated either every X many communications with a peer or every X minutes. Every 10MB or every 2 hours is a recommended default.
-    All valid requests with HMAC should be recorded until used HMAC's expiry to prevent replay attacks.
-    Peer Types
-        * Friends:
-            * Encrypted ‘friends only’ posts to one another
-            * Usually less strict rate & storage limits
-            * OPTIONALLY sign one another’s keys. Users may not want to do this in order to avoid exposing their entire friends list.
-        • Strangers:
-            * Used for storage of encrypted or public information
-            * Can only read public posts
-            * Usually stricter rate & storage limits
-## Data Storage/Delivery
 
-    Posts (public or friends only) are stored across the network.
-    Private messages SHOULD be delivered directly if both peers are online, otherwise stored in the network.
-    Data SHOULD be stored in an entirely encrypted state when a client is offline, including metadata. Data SHOULD be stored in a minimal size with garbage data to ensure some level of plausible deniablity.
-    Data SHOULD be stored as long as the node’s user prefers and only erased once disk quota is reached due to new data.
-    Posts
-    Posts can contain text and images. All posts MUST be time stamped.
-    Images SHOULD not be displayed by non-friends by default, to prevent unwanted viewing of offensive material & to reduce attack surface.
-    All received posts must be verified to be stored and/or displayed to the user.
+When a node first comes online, it attempts to bootstrap using a default list provided by a client.
+When two peers connect, they exchange Ed25519 keys (if applicable) then Salsa20 keys.
 
-    All data being transfered MUST be encrypted to the end node receiving the data, then the data MUST be encrypted the node(s) transporting/storing the data,
+Salsa20 keys are regenerated either every X many communications with a peer or every X minutes. 
 
-     Posts have two settings:
-        • Friends only:
-            ◦ Posts MUST be encrypted to all trusted peers via AES256-HMAC-SHA256 and PGP signed (signed before encryption) and time stamped to prevent replaying. A temporary RSA key for use in every post (or message) is exchanged every X many configured post (or message), for use in addition with PGP and the HMAC.
-        • Public:
-            ◦ Posts MUST be PGP signed, and MUST NOT use any encryption.
-## Private Messages
+Every 100kb or every 2 hours is a recommended default.
 
-    Private messages are messages that can have attached images. They MUST be encrypted via AES256-HMAC-SHA256 and PGP signed (signed before encryption) and time stamped to prevent replaying. A temporary EdDSA key for use in every message is exchanged every X many configured messages (or posts), for use in addition with PGP and the HMAC.
-    When both peers are online messages SHOULD be dispatched directly between peers.
-    All messages must be verified prior to being displayed.
+All valid requests with HMAC should be recorded until used HMAC's expiry to prevent replay attacks.
+Peer Types
+    * Friends:
+        * Encrypted ‘friends only’ posts to one another
+        * Usually less strict rate & storage limits
+    * Strangers:
+        * Used for storage of encrypted or public information
+        * Can only read public posts
+        * Usually stricter rate & storage limits
 
-    Clients SHOULD allow configurable message padding.
 ## Spam mitigation
 
 To send or receive data, a node can optionally request that the other node generate a hash that when in hexadecimal representation contains a random string at a random location in the string. Clients will configure what difficulty to request, and what difficulty is acceptable for themselves to perform. Difficulty should correlate with recent network & disk usage and data size. Friends can be configured to have less strict (to non existent) limits, separately from strangers. (proof of work).
-Rate limits can be strict, as Onionr is not intended to be an instant messaging application.
+Rate limits can be strict, as Onionr is not intended to be an instant messaging application.