Files: c0c9508d732a53b79ef287fd75268ac0d50dda3a / tmpl / more / protocols / secure-scuttlebutt.html.js
8320 bytesRaw
1 | var page = require('../../page.part') |
2 | var com = require('../../com.part') |
3 | |
4 | module.exports = () => page({ |
5 | title: 'Secure Scuttlebutt', |
6 | section: 'more', |
7 | tab: 'more-protocols', |
8 | path: '/more/protocols/secure-scuttlebutt.html', |
9 | content: ` |
10 | <h2>Secure Scuttlebutt</h2> |
11 | <p>Secure Scuttlebutt is a database protocol for unforgeable append-only message feeds.</p> |
12 | <p> |
13 | "Unforgeable" means that only the owner of a feed can update that feed, as enforced by digital signing (see <a href="#security-properties">Security properties</a>). |
14 | This property makes Secure Scuttlebutt useful for peer-to-peer applications. |
15 | Secure Scuttlebutt also makes it easy to encrypt messages. |
16 | </p> |
17 | |
18 | <hr> |
19 | |
20 | <h2>Overview</h2> |
21 | <p> |
22 | Scuttlebot forms a global cryptographic social network with its peers. |
23 | Each user is identified by a public key, and publishes a log of signed messages, which other users follow socially. |
24 | </p> |
25 | <p> |
26 | Scuttlebot searches the P2P mesh for new messages and files from followed users and from FoaFs. |
27 | The messages and files are stored locally, indefinitely, for applications to read. |
28 | </p> |
29 | |
30 | <h3>Identity</h3> |
31 | <p> |
32 | Users are identified by confirmations and signals in the social graph. |
33 | This is known as a Web-of-Trust. |
34 | There is no global registry of usernames. |
35 | Instead, users name themselves, and share petnames for each other. |
36 | </p> |
37 | <p> |
38 | Discovery occurs by examining the social graph, or by out-of-band sharing. |
39 | Applications can analyze the follow-graph, and look for "flag" messages, to determine who is trust-worthy in the network. |
40 | </p> |
41 | |
42 | <h3>Pub Servers</h3> |
43 | <p> |
44 | "Pubs" are bot-users that have public IPs. |
45 | They follow users and rehost the messages to other peers, ensuring good uptime and no firewall blockage. |
46 | </p> |
47 | <p> |
48 | Pubs have no special privileges, and are not trusted by users. |
49 | However, because Scuttlebot has no DHT or NAT-traversal utilities, users must "join" a Pub to distribute their messages on the WAN. |
50 | </p> |
51 | <p> |
52 | Scuttlebot can change Pubs, or join more than one, and sync directly over Wifi. |
53 | Identity is not tied to the Pubs. |
54 | </p> |
55 | |
56 | <hr> |
57 | |
58 | <h2 id="concepts">Concepts in Depth</h2> |
59 | <p>Building upon Secure Scuttlebutt requires understanding a few concepts that it uses to ensure the unforgeability of message feeds.</p> |
60 | |
61 | <h3 id="identities">Identities</h3> |
62 | <p> |
63 | An identity is simply a <a href="http://ed25519.cr.yp.to/">ed25519 key pair</a>. |
64 | The public key is used as the identifier. |
65 | </p> |
66 | <p> |
67 | There is no worldwide store of identities. |
68 | Users must exchange pubkeys, either by publishing them on their feeds, or out-of-band. |
69 | </p> |
70 | |
71 | <h3 id="feeds">Feeds</h3> |
72 | <p> |
73 | A feed is a signed append-only sequence of messages. |
74 | Each identity has exactly one feed. |
75 | </p> |
76 | <p> |
77 | Note that append-only means you cannot delete an existing message, or change your history. |
78 | This is enforced by a per-feed blockchain. |
79 | This is to ensure the entire network converges on the same state. |
80 | </p> |
81 | |
82 | <h3 id="messages">Messages</h3> |
83 | <p>Each message contains:</p> |
84 | <ul> |
85 | <li>A signature</li> |
86 | <li>The signing public key</li> |
87 | <li>A content-hash of the previous message</li> |
88 | <li>A sequence number</li> |
89 | <li>A timestamp</li> |
90 | <li>An identifier of the hashing algorithm in use (currently only "sha256" is supported)</li> |
91 | <li>A content object</li> |
92 | </ul> |
93 | <p>Here's an example message:</p> |
94 | ${ com.code({ js: `{ |
95 | "previous": "%26AC+gU0t74jRGVeDY01...MnutGGHM=.sha256", |
96 | "author": "@hxGxqPrplLjRG2vtjQL87...0nNwE=.ed25519", |
97 | "sequence": 216, |
98 | "timestamp": 1442590513298, |
99 | "hash": "sha256", |
100 | "content": { |
101 | "type": "vote", |
102 | "vote": { |
103 | "link": "%WbQ4dq0m/zu5jxll9zUb...KjZ80JvI=.sha256", |
104 | "value": 1 |
105 | } |
106 | }, |
107 | "signature": "Sjq1C3yiKdmi1TWvNqxI...gmAQ==.sig.ed25519" |
108 | }` }) } |
109 | |
110 | <h3 id="entity-references-links-">Entity References (Links)</h3> |
111 | <p> |
112 | Messages can reference three types of Secure Scuttlebutt entities: messages, feeds, and blobs (i.e. files). |
113 | Messages and blobs are referred to by their hashes, but a feed is referred to by its signing public key. |
114 | </p> |
115 | |
116 | <h3 id="confidentiality">Confidentiality</h3> |
117 | <p> |
118 | For private sharing, Scuttlebot uses <a href="http://doc.libsodium.org/">libsodium</a> to encrypt confidential log-entries. |
119 | Feed IDs are public keys, and so once two feeds are mutually following each other, they can exchange confidential data freely. |
120 | </p> |
121 | |
122 | <h3 id="following">Following</h3> |
123 | <p> |
124 | Users choose which feeds to synchronize by following them. |
125 | Presently, <a href="/modules/scuttlebot-replicate.html">Scuttlebot's replicate plugin</a>, which is enabled by default, looks on the master user's feed for <code>type:contact</code> messages to know which users are currently followed. |
126 | </p> |
127 | |
128 | <h3 id="replication">Replication</h3> |
129 | <p> |
130 | Since feeds are append-only, replication is simple: request all messages in the feed that are newer than the latest message you know about. |
131 | Scuttlebot maintains a table of known peers, which it cycles through, asking for updates for all followed feeds. |
132 | </p> |
133 | |
134 | <h3 id="gossip">Gossip</h3> |
135 | <p> |
136 | The protocol creates a <a href="https://en.wikipedia.org/wiki/Gossip_protocol">global gossip network</a>. |
137 | This means that information is able to distribute across multiple machines, without requiring direct connections between them. |
138 | </p> |
139 | <p><img src="/img/gossip-graph1.png" alt="Gossip graph"></p> |
140 | <p>Even though Alice and Dan lack a direct connection, they can still exchange feeds:</p> |
141 | <p><img src="/img/gossip-graph2.png" alt="Gossip graph 2"></p> |
142 | <p> |
143 | This is because gossip creates "transitive" connections between computers. |
144 | Dan's messages travel through Carla and the Pub to reach Alice, and visa-versa. |
145 | </p> |
146 | |
147 | <h3 id="lan-connectivity">LAN connectivity</h3> |
148 | <p> |
149 | SSB is hostless: each computer installs the same copy of software and has equal rights in the network. |
150 | Devices discover each other over the LAN with multicast UDP and sync automatically. |
151 | </p> |
152 | |
153 | <h3 id="pub-servers">Pub Servers</h3> |
154 | <p> |
155 | To sync across the Internet, "Pub" nodes run at public IPs and follow users. |
156 | They are essentially mail-bots which improve uptime and availability. |
157 | Users generate invite-codes to command Pubs to follow their friends. |
158 | The Scuttlebot community runs some Pubs, and anybody can create and introduce their own. |
159 | </p> |
160 | |
161 | <h2 id="security-properties">Security properties</h2> |
162 | <p> |
163 | Secure Scuttlebutt maintains useful security properties even when it is connected to a malicious Secure Scuttlebutt database. |
164 | This makes it ideal as a store for peer-to-peer applications. |
165 | </p> |
166 | <p> |
167 | Imagine that we want to read from a feed for which we know the identity, but we're connected to a malicious Secure Scuttlebutt instance. |
168 | As long as the malicious database does not have the private key: |
169 | </p> |
170 | <ul> |
171 | <li>The malicious database cannot create a new feed with the same identifier</li> |
172 | <li>The malicious database cannot write new fake messages to the feed</li> |
173 | <li>The malicious database cannot reorder the messages in the feed</li> |
174 | <li>The malicious database cannot send us a new copy of the feed that omits messages from the middle</li> |
175 | <li>The malicious database <em>can</em> refuse to send us the feed, or only send us the first <em>N</em> messages in the feed</li> |
176 | <li>Messages may optionally be encrypted</li> |
177 | </ul> |
178 | <p> |
179 | Additionally there is a protection from the feed owner, through the blockchain. |
180 | The <code>previous</code> content-hash them from changing the feed history after publishing, as a newly-created message wouldn't match the hash of later messages which were already replicated. |
181 | This ensures the append-only constraint, and thus safe network convergence. |
182 | </p> |
183 | `, |
184 | next: ['/more/protocols/secret-handshake.html', 'Secret Handshake'] |
185 | }) |
Built with git-ssb-web