[liberationtech] Why_can't_email_be_secure

coderman coderman at gmail.com
Mon Aug 26 00:55:11 PDT 2013


On Sun, Aug 25, 2013 at 10:52 PM, Bill Stewart <bill.stewart at pobox.com> wrote:
> ...
> Because "low latency protocols that are resistant to traffic analysis"
> is a really really hard problem.  Even doing
> "high latency protocols that are resistant to traffic analysis"
> is a really hard problem.

the best kind of problems!



> Datagrams don't give you any useful anonymity,

correct. i mention them as a prerequisite for both protection and usability.

protection for example, with end-to-end SCTP multi-homed endpoints via
userspace stacks would avoid predecessor attacks - if you block one
route there are others which transit traffic, maintaining an
uninterrupted session across otherwise individually volatile paths.

usability for example to support UDP traffic and applications which
are not currently served via TCP and connection oriented services.



> ...
> The standard warning about using them for an application is
> that it's extremely tempting to use them to reinvent TCP badly,

sadly, even TCP re-invented in user space is insufficient. you want a
specific protocol implementation of multi-homed SCTP in userspace,
probably on top of other protocol supports like LEDBAT or AQM. perhaps
using ORCHID IPv6 identifiers for endpoint addressing. lot's of
options; and as you said: it's a hard problem!



> Some other problems with them are that you need to ...
> disguise them as other protocols.

this is a separate problem. for the core transport encapsulation in
UDP may be sufficient. for censorship avoidance you will likely need
to bounce over a DUST like path first to access such an anonymizing
network. topology is an interesting subject, as the design must be
decentralized but may not need to be homogenous.



> Putting them in user space is just fine and mostly more portable.
> It's hard to get millisecond-level latency if you do that,
> but you can't hide from traffic analysis with latency that low anyway.

you want variable latency at the datagram level (e.g. stochastic
reordering and shaping of traffic, with prioritization done at the
endpoint where flows are visible.) more than the utmost in
performance. as long as it is overall TCP fair of course :)



and this is just the start. we haven't touched on network discovery,
path awareness/selection/weighting, etc.  as you said, hard problems;
the best kind of problems!



More information about the cypherpunks mailing list