aort...@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,
Jacob

_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to