[cryptography] Potential funding for crypto-related projects
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