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
