[cryptography] Potential funding for crypto-related projects

Jacob Appelbaum jacob at appelbaum.net
Tue Jul 2 09:39:00 EDT 2013

aortega at alu.itba.edu.ar:
>>> The more interesting point is high vs low latency. I really like the
>>> idea of having a high-latency option in Tor. It would still need to
>>> have a lot of users to actually be useful, though. But it seems there
>>> are various protocols that would be ore high-latency-friendly than
>>> HTTP - SMTP, of course, and XMPP spring to mind.
>> I think if Tor had an arbitrary queue with store and forward as a high
>> latency module of sorts, we'd really be onto something. Then there would
>> be tons of traffic on the Tor relays for all kinds of reasons - high and
>> low latency - only to all be wrapped in TLS and then in the Tor protocol.
> I was looking for something like this. It would be incompatible with
> anything that uses TCP, but better that way. I have always found weird
> that there is no a UDP-like transport in tor.

I'm not sure that this is true. Mixminion uses TCP, for example.

> IMHO only the TCP initial hand-shake gives your attacker enough info to
> leak your position easily (just a tought, never did any sort of serious
> tests on this) but UDP would be immune to it, even more if it's
> implemented using high-latency queues. Probably most existing UDP services
> should work unmodified.

Tor does not transport connections - it transports streams. The
connection setup happens at the exit node - which is already a known
list of ip addresses.

All the best,

More information about the cryptography mailing list