minion-design.pdf / low bandwidth high latency long term connections

Zenaan Harkness zen at freedbms.net
Tue Oct 22 13:31:00 PDT 2019


On Tue, Oct 22, 2019 at 11:03:59AM +1100, Zenaan Harkness wrote:
> On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
> > 
> > 	courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia. 
> > 
> > 
> > 	anyway :  https://www.mixminion.net/minion-design.pdf
> 
> Have not begun to read that yet, but one of the stream covfefe will
> "recommend as a default for all users" is a really low bandwidth
> ("bw") and high latency, permanent connection.
> 
> 1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks
> will complain.
> 
> But let's consider just 512 bytes every 10 minutes (a single small
> UDP packet):
> 
>   1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month
> 
>   each message send can contain up to 512 / 128 = 4 "std tweets"
>   therefore 17,280 "std tweets" at 10 minute latency
> 
>   at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month
> 
> NOW we're talking some serious chaff for high value random tweets at
> any time, with a maximum latency of 10 minutes, for only 2.1MiB of
> bandwidth per month!
> 
> No doubt some folks can imagine some nice applications for this
> "recommended baseload" stream :)
> 
> Now, if your mixing, then those 17,280 tweets need to be divided by
> the "mixing hop count" to work out actual payload, so let's say your
> actual tweets go through 10 hops, we have (up to) 1,728 high value
> tweets per node, per month, with possibly up to 10*10=100 minutes
> maximum latency (although I'm confident we can eliminate most of that
> with nodes cascading off one another in waves, so that maximum
> latency should be at most say 30 time units.
> 
> If we need lower latency, say 1 minute, we're still only talking
> 21MiB bandwidth per month - and as a bonus we have 10 fold message
> capacity, for 1/10th the latency, a win win (except on the bw front
> of course).
> 
> To repeat a key point from a previous email: by treating different
> types of streams for their own nature, we can not only reason about
> network impact and various performance metrics, but we can ensure
> that any design caters to include that type of stream.


A high value but rare text message, still has at least one recipient.

An adversary will seek to discover "who are the end parties sending
messages to one another".

Besides cracking end user computers, one can imagine GPA stalker
nodes introducing say latency jitter at one point in the net, and
detecting that jitter at another point in the net.

Such attacks are why the only sane entry to IQNets is via at least
one 'trusted' friend.

To increase stalker difficulty, we can imagine:

  - sending encrypted message to multiple friends
  - either in a star/ multi cast model
  - or in a token ring/ each always sends to next hop model

  - my first hop could just be a standard route ABC,
    where B is a 'trusted' net entry friend providing me his node as
    a hop which I may use to enter the network
  - then, my next hop to C could be to another friend/ 'trusted' node
    which runs a low-vol high-value text message "repeater" to
    everyone in my little circle, and possibly the odd random target
    (by sending a chaff fill packet); this is the star topo
  - alternatively in the token ring topo (topology), the 1st
    recipient sends the message to the 2nd, who on sends in to the 3rd
    etc, and the last in the ring finally sends it back to me (they
    don't necessarily know or realise that I originated this
    particular message)
    - once I receive my own message back, I know everyone in the ring
      has at least received it
    - this has the effect of total propagation duration (the total
      time for everyone to receive the message) scaling (increasing)
      according to the number of recipients/participants in the ring

  - to receive confirmation when using the star (as opposed to ring)
    topo, I receive an ack from each recipient;
    - this scales the number of ACKs according to the number of
      recipients

  - so different models have different properties

  - the low volume, potentially high value, relatively high latency
    text message stream, if it involves an ACK, can be considered a
    form of ping

  - a group of texting friends in a ring has the problem that if one
    recipient drops out, the next recipient may lose a message, and
    therefore needs to know about the prior hop in the ring (the node
    before the friend who dropped out) to ask for any messages or
    pings that have been dropped/missed, and similarly, the node
    before that if both nodes drop out, etc

  - star topo is how the typical internet "chat room" works



More information about the cypherpunks mailing list