[katzenpost] mixnet notes from visit to KU Leuven

[Kali Kaneko]

In reply to some transmogrified bits by kaliyuga at riseup.net on the 2018-02-08 21:27:15:

oops, sorry, I didn't mean to encrypt that. re-sending.

> In reply to some transmogrified bits by yawning at schwanenlied.me on the 2018-02-08 16:38:01:
> 
> >    Right now there is one (network wide) parameter `LambdaP`, that
> >    specifies the mean of a Poisson distribution (in seconds).  The
> >    client will attempt to send traffic (be it cover or otherwise) by
> >    sampling from this distribution.
> > 
> >    Note: This is distinct from the (network wide) `Lambda` which is
> >    used to derive mixing delay.
> > 
> >    Should there be separate parameter(s) for decoy traffic?  If so how
> >    should it be parameterized?
> 
> At the risk of talking nonsense, I'll venture here than ideally this should be 
> parametrized dinamically by the mix authority. I do not know much about proper 
> theoretical approaches, but my gut feeling (and what I got from the talk with 
> Claudia) is that whatever decoy traffic modelling we end up using needs to be 
> adjusted dynamically in response to some property of the global system (or 
> otherwise this will be getting into some absurd delay vs. bandwith tradeoffs - 
> did you get to talk about this in the other day's call?).
> 
> This leads me to think that the authority could publish some aggregate of the 
> total traffic, does this make sense? (inputs could be received via a mix path to 
> an agent).
> 
> I get that the current state of things is "wait to read the latest paper on the 
> topic", but I'd be interested in hearing some further thoughts on this in the 
> meantime. For us this is going to be a crucial point to make this deployable in 
> the real world (tm).
> 
> >  * What fraction of client decoy traffic should be loop vs discard?
> > 
> >  * What actions if any should a client take if loop decoy traffic fails
> >    to loop?  How is the client supposed to combat false positives?
> 
> I'd say fail close: after a statistically meaningful threshold client should 
> block normal operation. then it could check some view of the health of the 
> mixes, and report anomaly to user if network is healthy (but, how to distinguish 
> that from congestion?)
> 
> > General questions:
> > 
> >  * How should a mix behave when it encounters a packet with exactly
> >    `0` delay?
> 
> Can a well-behaved client choose 0 delay? I was assuming that the delays were an 
> open interval. If so, the only application for this that I can see is to measure 
> performance.  If those assumptions are tru, I'd say drop as badly formed 
> packets, *unless* the mix is running with some kind of debug flag.
>  
> --
> We reject kings, presidents and voting.
> We believe in rough consensus and working code.

--
We reject kings, presidents and voting.
We believe in rough consensus and working code.