akwizgran deleted page: Concepts

Concepts.markdown

@@ -1,124 +0,0 @@
-# Repeaters
-The idea of repeaters has been kicking around for a while but we've never really gone into the details. Repeaters were proposed to address
-a few use cases:
-
-1. Alice uses Briar on a device that isn't always online. She has another device that's online most of the time (such as a Raspberry Pi, a VPS, or a second phone that she leaves at home). It would be useful if her contacts could connect to that other device when they can't reach her directly and leave encrypted data there to be collected
-later, or collect any data that she's left for them.
-
-2. Alice belongs to a community of people who use Briar on devices
-that aren't always online. She has another device that's online most
-of the time. It would be useful if the other members of the community
-could connect to that device when they can't reach each other directly
-and leave encrypted data there to be collected later, or collect any
-data that's been left for them.
-
-3. Like use case 2, but without internet access. Alice belongs to a
-community of people who use Briar on devices that aren't always within
-wifi range of each other. She has another device that sits on a wifi
-network that members of the community often use (perhaps she runs a
-cafe). It would be useful if other members of the community could
-connect to that device when they can't reach each other directly and
-leave encrypted data there to be collected later, or collect any data
-that's been left for them.
-
-I used to think that when we got into the details of repeaters we'd
-find that these use cases were variants of the same basic idea. But
-I'm starting to think that the first use case is actually quite different.
-
-The difference is authentication. In use case 1, it makes sense for
-Alice's contacts to authenticate themselves to the repeater - we don't
-want strangers to be able to abuse the repeater, and it's OK for the
-repeater to know which contacts Alice is communicating with, because
-it belongs to Alice, who knows that anyway.
-
-In use cases 2 and 3, on the other hand, we might want people who
-aren't Alice's contacts to benefit from the repeater, but we don't
-want the repeater to know too much about who's communicating,
-otherwise Alice could use the repeater to spy on the rest of the
-community. So instead of authentication we actually want anonymity.
-But we have to find a way to prevent anonymous users from abusing the
-repeater.
-
-Since these use cases lead to quite different requirements I'm going
-to call the thing that addresses use case 1 a repeater, and the thing
-that addresses use cases 2 and 3 a dead drop.
-
-A repeater looks like something we could build with BTP and BMP:
-
-* Alice, Bob and the repeater share a private BMP group
-* Alice creates an Alice-to-Bob BTP stream
-* Alice encapsulates the stream in a BMP message
-* Alice syncs the message to the repeater inside an Alice-to-repeater
-BTP stream
-* The repeater syncs the message to Bob inside a repeater-to-Bob BTP
-stream
-* Bob unencapsulates the Alice-to-Bob BTP stream
-
-A dead drop, on the other hand, doesn't fit well with BTP and BMP,
-which both assume you know who you're talking to. A dead drop might
-actually make more sense as a standalone project. If we design it
-right I think it could be useful to other projects too.
-
-There are two tricky aspects to a dead drop. The first is anonymity.
-To what extent can clients really be anonymous? In use case 2, clients
-can connect to the dead drop over Tor, so it's possible for clients to
-be strongly anonymous to the dead drop - and vice versa, if we like.
-This starts to look rather like Pond.
-
-In use case 3, the dead drop can see clients' MAC addresses, so it
-will get some information about who's communicating. But it won't get
-any more information than it would get if the clients communicated
-directly with each other, and everyone else on the wifi network will
-get less information than they'd get if the clients communicated
-directly, so we may decide that's an acceptable information leak in a
-local context.
-
-The second tricky aspect is how to prevent anonymous clients from
-exhausting the dead drop's resources. I think we can use blinded
-signatures for that purpose. Here's a sketch of how it might work:
-
-Tokens
-======
-
-* Time is divided into rounds, e.g. one round per week
-* The server's storage space is divided into blocks, e.g. 1 MB per block
-* The server issues tokens to some clients, e.g. the owner's contacts,
-who may pass the tokens on to other clients
-* Each token is valid for one round
-* A token that's valid in round i can be used to store a block of data
-until the end of round i+1
-* A token can be used to store a new block or renew an existing block
-* Tokens are blinded before signing, so the server doesn't know which
-client a token was issued to
-* The server uses a new signature key for each round, so it knows
-which round a token is valid for
-* When client uses a token, the server gives the client a new token
-valid in the following round
-* A client can exchange an unused token that was valid in a previous
-round for a new token valid in the current round
-* Tokens eventually expire and can no longer be exchanged - this
-prevents lost tokens from permanently reserving space
-
-Uploads
-=======
-
-* A client can upload a file by sending sufficient tokens and
-specifying a name for the file
-* Names are allocated on a first come, first served basis
-* Uploads may be padded to hinder traffic analysis
-* Encryption and server-to-client authentication are mandatory for the
-upload protocol
-* The upload protocol could be HTTPS
-
-Downloads
-=========
-
-* A client can list the available files and download them by name
-* Encryption and server-to-client authentication are optional for the
-download protocol
-* The download protocol could be HTTP or HTTPS
-
-This design can be used for storing BTP streams - the pseudo-random
-tag is used as the filename, so the recipient knows which file to
-download. It can also be used for an anonymous, DoS-resistant
-pastebin, and possibly other things.