git ssb

1+

Kira / p2p-faq



Commit a338c42b5787ed52b50778d8ddc9604a7e97af83

Merge remote-tracking branch 'matthiasbeyer/security-of-p2p-websites'

Stephen Whitmore committed on 1/9/2018, 8:13:01 PM
Parent: 756734913c379760350969890a4c483fca9d1f06
Parent: ab39e58bd5cdc80a3c9556a45bc3278a58084f00

Files changed

README.mdchanged
README.mdView
@@ -59,8 +59,10 @@
5959 content.
6060
6161 ## 3. What about security? Somebody could share a hacked version of a p2p website?
6262
63 +*From @noffle:*
64 +
6365 It depends what the security model of the system hosting the website uses. There
6466 are two commonly tools I know of for ensuring that a copy of data you've
6567 received from a potentially untrusted source is authentic:
6668
@@ -81,8 +83,24 @@
8183 content-addressed above. [Dat](https://dat-project.org),
8284 [IPFS](https://ipfs.io) and [SSB](https://scuttlebutt.nz) all use this
8385 approach for dynamic data.
8486
87 +*From @matthiasbeyer:*
88 +
89 +If cryptographic signatures come into play, this is not possible.
90 +
91 +Consider a content-addressed system. In such systems, content is addressed via
92 +a cryptographic hash which represents the content. For example, a file
93 +containing "Hello World" gets a hash "648a6a6ffff".
94 +If a peer now tries to fetch content from the network, it does so by asking
95 +for the content of "648a6a6ffff".
96 +If it gets sent this content, it can then verify with that same hash,
97 +whether the content it got is the actual content it requested.
98 +
99 +An attacker would be able to host malicious nodes in the network, but as the
100 +node which _requests_ the content (your node) can verify that it got what it
101 +expected.
102 +
85103 ## 4. What about privacy? Everybody in the p2p network can see what I am looking at.
86104
87105 *TODO*
88106

Built with git-ssb-web