[tor-talk] On the Theory of Remailers

[Tom Ritter]

I'm hoping this will be of interest to this list. To encourage
interest in the waning art of remailers, I'm starting what I aim to be
a long series on how they work, design choices, technical limitations,
and attacks. The first five are now live at https://crypto.is/blog/

-tom

[David H. Lipman]

From: "Tom Ritter" <tom at ritter.vg>

Post by Tom Ritter
I'm hoping this will be of interest to this list. To encourage
interest in the waning art of remailers, I'm starting what I aim to be
a long series on how they work, design choices, technical limitations,
and attacks. The first five are now live at https://crypto.is/blog/

I hope you fully elaborate on how remailers are used for abuse.

[Moritz Bartl]

Post by David H. Lipman

Post by Tom Ritter
I'm hoping this will be of interest to this list. To encourage
interest in the waning art of remailers, I'm starting what I aim to be
a long series on how they work, design choices, technical limitations,
and attacks. The first five are now live at https://crypto.is/blog/

I hope you fully elaborate on how remailers are used for abuse.

Without being racial, sounds like an "American idea" to me, similar to
crazy Disclaimers on almost every product. If every system ever invented
would come with an elaboration on how it is being abused (hey, that's in
the name, AB-USE) that list would most likely be illegal for most things
(because assisting crime is illegal in most places) and otherwise very
tiresome.

If you are looking for studies on abuse of remailer technology, no
larger instance so far bothers to collect figures. Same for Tor. How
could Tom know?

Yes, this is indeed a sad state. Everything and everyone needs more open
data.

As one data point, unlikely to be of relevance for neither Tor nor
remailers: We run both, and judging from a comparison of bandwidth
consumption or passed messages vs. abuse complaints (because that's all
I can take into account): widely below one percent. That's my rough
estimate -- sorry, I would like to have better statistics but I
currently don't. Are there any on "general abusive Internet traffic"?
What is that? In the case of remailers, it's additionally hard because
of all the dummy traffic.

Also, in the end all abuse statistics can and always will be only about
"reported abuse", not actual abuse.

[David H. Lipman]

From: "Moritz Bartl" <moritz at torservers.net>

Post by Moritz Bartl

Post by David H. Lipman

Post by Tom Ritter
I'm hoping this will be of interest to this list. To encourage
interest in the waning art of remailers, I'm starting what I aim to be
a long series on how they work, design choices, technical limitations,
and attacks. The first five are now live at https://crypto.is/blog/

I hope you fully elaborate on how remailers are used for abuse.

Without being racial, sounds like an "American idea" to me, similar to
crazy Disclaimers on almost every product. If every system ever invented
would come with an elaboration on how it is being abused (hey, that's in
the name, AB-USE) that list would most likely be illegal for most things
(because assisting crime is illegal in most places) and otherwise very
tiresome.

I'm afraid you are as YOU state "sounds like an "American idea" to me"...

Post by Moritz Bartl
If you are looking for studies on abuse of remailer technology, no
larger instance so far bothers to collect figures. Same for Tor. How
could Tom know?
Yes, this is indeed a sad state. Everything and everyone needs more open
data.
As one data point, unlikely to be of relevance for neither Tor nor
remailers: We run both, and judging from a comparison of bandwidth
consumption or passed messages vs. abuse complaints (because that's all
I can take into account): widely below one percent. That's my rough
estimate -- sorry, I would like to have better statistics but I
currently don't. Are there any on "general abusive Internet traffic"?
What is that? In the case of remailers, it's additionally hard because
of all the dummy traffic.
Also, in the end all abuse statistics can and always will be only about
"reported abuse", not actual abuse.

I am not basing it on abuse complaints, I am basing it based upon viewed
abuse. I have been on Usenet a long time and I often see remailers used to
post abuse to Usenet. I have seen personal attack campaigns using numerous
systems to perform the attacks such as; dizum.com, remailer.privacy.at,
remailer.paranoici.org and anonymitaet-im-inter.net to name a few. Te
systems were used for privacy b ut were used tol obfuscate one's identity
whiles committing the abuse of an individual or on Usenet as a whole.

BTW: Since you have www.torsewrvers.net in your signature, I will also add
that I have seen Usenet abuse through that system as well.

The following is an example of a very recent spam campaign
Message-ID: <3f25c5add3e59183593b48fcca0bb65c at foto.ro1.torservers.net>

[Tom Ritter]

Post by David H. Lipman
I hope you fully elaborate on how remailers are used for abuse.
--
Dave

I intend to, but I've never been the receiving end of remailer abuse,
so I've only got academic knowledge. I had a few ideas I was
brainstorming about this:

1) a shared, hashed list of emails to provide a 'global' opt-out of
emails for all participating nodes
2) For plaintext mails, adding a spam filter on outgoing mails
3) some form of 'status' remailers could publish where a client could
see that their email was either delivered, flagged as spam by a
remailer's exit policy, or just never recieved.

And advantage of 3 is that it helps with the reliability quesiton: did
my message get delivered? A disadvantage is it requires a client to
remember a GUID of a message that would tie the user to the message
(very bad).

That's all assuming you mean abuse from the perspective of the
recipient, and not abuse form the perspective of the remailer
operator.

-tom

[adrelanos]

Post by Tom Ritter
I'm hoping this will be of interest to this list. To encourage
interest in the waning art of remailers, I'm starting what I aim to be
a long series on how they work, design choices, technical limitations,
and attacks. The first five are now live at https://crypto.is/blog/
-tom

Appreciated. I am curious about high latency networks.

The articles look good from a quick look. Will thoroughly read all of them.

My favorite mail about remailing and Tor:
http://www.mail-archive.com/liberationtech at lists.stanford.edu/msg00022.html

It is an interesting questions, if with a modern user interface, can they
get to new life?

I am also working on integrating them into Whonix, using Mixmaster over Tor:
https://sourceforge.net/p/whonix/wiki/Mixmaster/

[grarpamp]

Post by adrelanos
It is an interesting questions, if with a modern user interface, can they
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today. Even if only
10% ran them it would probably be more hosts than were ever
behind the old remailer nets. And relay operators already have the
abuse experience in place.

[Moritz Bartl]

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can they
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today.

In the end, both low and high latency anonymity should be handled by the
same network.

[Tom Ritter]

Post by Moritz Bartl

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can they
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today.

In the end, both low and high latency anonymity should be handled by the
same network.

I believe this is the concept behind Alpha Mixing [0]. When I talked
to Roger once, many moons ago, I recall he expressed the desire that
one day, in an ideal world, Alpha Mixing would indeed be the main
mixing of the network, to allow for transit of other types of things,
like email.

-tom

[0] http://www.freehaven.net/doc/alpha-mixing/alpha-mixing.pdf

[Eugen Leitl]

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can they
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today. Even if only
10% ran them it would probably be more hosts than were ever
behind the old remailer nets. And relay operators already have the
abuse experience in place.

Most exit operators block port 25 -- for a very good reason.

[adrelanos]

Post by Eugen Leitl

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can

they

Post by adrelanos
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today. Even if only
10% ran them it would probably be more hosts than were ever
behind the old remailer nets. And relay operators already have the
abuse experience in place.

Most exit operators block port 25 -- for a very good reason.

Please don't easily dispose remailers and look at their potential.

High latency networks are not tied to port 25. They could use any port.
Even if the Tor exit operators don't want to be in an exit position for
e-mail traffic, they could still be a middle node.

Neither remailers are tied to clearnet spam. If we assume that remailers
can not be used to mail people in normal internet because of spam, they
could mimic "hidden services", i.e. internal mail addresses only known to
the people who should know them.

Pseudonymous reply address for remailers:
http://www.mixnym.net/

Remailers aren't tied to messaging as well.

Nymserver can also fetch websites with high latency. In theory high
latency networks complement low latency networks such as Tor and can
provide strong anonymity.

[Alexandre Guillioud]

Hi all,

I'm reading your conversation, and i'm not understanding very well what you
mean by high/low latency network. Isn't it just a ping duration delta ?
You speak about low and high latency like it's a feature.

Is tor mixing only low latency with low latency in its circuits ? Opening
for a dispatching of services (ie. mail on high latency, web on low ) ?

What's the point ?

2013/1/8 <adrelanos at riseup.net>

Post by adrelanos

Post by Eugen Leitl

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can

they

Post by adrelanos
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today. Even if only
10% ran them it would probably be more hosts than were ever
behind the old remailer nets. And relay operators already have the
abuse experience in place.

Most exit operators block port 25 -- for a very good reason.

Please don't easily dispose remailers and look at their potential.
High latency networks are not tied to port 25. They could use any port.
Even if the Tor exit operators don't want to be in an exit position for
e-mail traffic, they could still be a middle node.
Neither remailers are tied to clearnet spam. If we assume that remailers
can not be used to mail people in normal internet because of spam, they
could mimic "hidden services", i.e. internal mail addresses only known to
the people who should know them.
http://www.mixnym.net/
Remailers aren't tied to messaging as well.
Nymserver can also fetch websites with high latency. In theory high
latency networks complement low latency networks such as Tor and can
provide strong anonymity.
_______________________________________________
tor-talk mailing list
tor-talk at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[Tom Ritter]

On 9 January 2013 10:05, Alexandre Guillioud

Post by Alexandre Guillioud
Hi all,
I'm reading your conversation, and i'm not understanding very well what you
mean by high/low latency network. Isn't it just a ping duration delta ?
You speak about low and high latency like it's a feature.
Is tor mixing only low latency with low latency in its circuits ? Opening
for a dispatching of services (ie. mail on high latency, web on low ) ?
What's the point ?

Someone can probably explain it better by putting more time into it,
but the gist of it is how long a mix node will 'hold onto' a message,
before sending it on. (Effectively 'mixing' it.)

Post by Alexandre Guillioud
A 'Low Latency' mix network means as soon as a node receives a packet, it sends it out. A 'High Latency' mix network means a node will hold onto a message for some amount of time before sending it out.
Traffic Analysis is a huge part of mix network design. If an attacker is watching the network (and we generally assume they are) - how much information do they gain by watching packet paths, sizes, and times, and how easy is it? If you see a network flow from Alice to Bob, and Bob to Charlie - those flows will probably be matchable. With regard to defending against Traffic Analysis, High Latency is preferable - being able to hold onto a packet for any length of time before sending it on gives you lot more options.
Tor is a 'Low Latency' mix network - it has no choice because it's infeasible to browse the Internet with minute-long (or longer) delays during page loads. However, email can have delays - if an email doesn't arrive for 30 minutes or an hour, it's generally not a problem. So Remailers can afford to be a High Latency mix network. They will accumulate a number of messages in a pool, and then when the pool is a certain size, will send the messages out. There are multiple algorithms for pooling, and we'll go into more detail about them and pool attacks later.

As a mix node, if I accumulate 8 same-size messages, and then send
them all out at once to 8 recipients, you can't use traffic analysis
to see who I sent which message out to - because they're
indistinguishable. That's high latency. But if I had sent out each
message as soon as I got it, you could see which message went to each
recipient - that's low latency.

-tom

[Alexandre Guillioud]

Wooo thank's Tom ! First time using mailing lists, i'm going to like it :D
(and it's not a problem to answer from work :DD).
Ok, so i understand what you're meaning by high/low latency network.

Just, why don't apply this to web browsing ? Can't each node keep packet up
to 5 seconde based on random ? 5 second isn't a problem, as tor network is
already long to serve pages/packets.

From my point of view, you can't allow some sort of different latency

paths for clients.
It will confuse basics users,
And power users will tweak this to allow only low latency circuits.

2013/1/9 Tom Ritter <tom at ritter.vg>

On 9 January 2013 10:05, Alexandre Guillioud

Post by Alexandre Guillioud
Hi all,
I'm reading your conversation, and i'm not understanding very well what

you

Post by Alexandre Guillioud
mean by high/low latency network. Isn't it just a ping duration delta ?
You speak about low and high latency like it's a feature.
Is tor mixing only low latency with low latency in its circuits ? Opening
for a dispatching of services (ie. mail on high latency, web on low ) ?
What's the point ?

Someone can probably explain it better by putting more time into it,
but the gist of it is how long a mix node will 'hold onto' a message,
before sending it on. (Effectively 'mixing' it.)

Post by Alexandre Guillioud
A 'Low Latency' mix network means as soon as a node receives a packet,

it sends it out. A 'High Latency' mix network means a node will hold onto a
message for some amount of time before sending it out.

Post by Alexandre Guillioud
Traffic Analysis is a huge part of mix network design. If an attacker is

watching the network (and we generally assume they are) - how much
information do they gain by watching packet paths, sizes, and times, and
how easy is it? If you see a network flow from Alice to Bob, and Bob to
Charlie - those flows will probably be matchable. With regard to defending
against Traffic Analysis, High Latency is preferable - being able to hold
onto a packet for any length of time before sending it on gives you lot
more options.

Post by Alexandre Guillioud
Tor is a 'Low Latency' mix network - it has no choice because it's

infeasible to browse the Internet with minute-long (or longer) delays
during page loads. However, email can have delays - if an email doesn't
arrive for 30 minutes or an hour, it's generally not a problem. So
Remailers can afford to be a High Latency mix network. They will accumulate
a number of messages in a pool, and then when the pool is a certain size,
will send the messages out. There are multiple algorithms for pooling, and
we'll go into more detail about them and pool attacks later.
As a mix node, if I accumulate 8 same-size messages, and then send
them all out at once to 8 recipients, you can't use traffic analysis
to see who I sent which message out to - because they're
indistinguishable. That's high latency. But if I had sent out each
message as soon as I got it, you could see which message went to each
recipient - that's low latency.
-tom
_______________________________________________
tor-talk mailing list
tor-talk at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[Tom Ritter]

On 9 January 2013 10:33, Alexandre Guillioud

Post by Alexandre Guillioud
Wooo thank's Tom ! First time using mailing lists, i'm going to like it :D
(and it's not a problem to answer from work :DD).
Ok, so i understand what you're meaning by high/low latency network.
Just, why don't apply this to web browsing ? Can't each node keep packet up
to 5 seconde based on random ? 5 second isn't a problem, as tor network is
already long to serve pages/packets.
From my point of view, you can't allow some sort of different latency
paths for clients.
It will confuse basics users,
And power users will tweak this to allow only low latency circuits.

Allowing a client to choose their 'delay' and combining low and high
latency networks is (as I understand it) the basis behind Alpha Mixing
[0].

As far as a 5 second window in Tor nodes - off the top of my head, I'm
not sure 5 seconds would really gain anything. If the nodes you're
using (.e.g bridges) aren't used much, 5 seconds doesn't help you. On
the other hand, adding 30 seconds (3 hops, 2 directions) to *each*
request, keeping in mind a page maybe have 20 requests quickly makes
web browsing near-unusuable.

The other elephant in the room is that *even with* high latency, given
*enough* traffic, you can always link it statistically. Think of it
this way: If I'm sending a packet a day to a recipient, you can see a
packet a second leave my machine, and a packet a day received at the
other end. Even if my message is mixed well, held for an hour and
mixed with other messages - it's not hard after a few days to realize
the correlation. High latency makes this harder, harder still if you
don't have a regular pattern. If statistically it's still easy, even
with a 5 second delay, what's the point in making the software harder
to use if you're not getting the defense you seek?

I'm not the authority on Tor's design decisions, but those are my thoughts.

-tom

[0] http://www.freehaven.net/doc/alpha-mixing/alpha-mixing.pdf

[Alexandre Guillioud]

My thought are as following. Why keep entropie where you can have chaos ?
I agree that tor is already CHAOS from an exterior point of view, but a
little more is never bad :D

Plus,

Post by Tom Ritter
If statistically it's still easy, even
with a 5 second delay, what's the point in making the software harder
to use if you're not getting the defense you seek?

What i was saying is no configuration for the end user. Just dispatch on
the first node on the most efficient circuits for the current datatype.

2013/1/9 Tom Ritter <tom at ritter.vg>

Post by Tom Ritter
On 9 January 2013 10:33, Alexandre Guillioud

Post by Alexandre Guillioud
Wooo thank's Tom ! First time using mailing lists, i'm going to like it

:D

Post by Alexandre Guillioud
(and it's not a problem to answer from work :DD).
Ok, so i understand what you're meaning by high/low latency network.
Just, why don't apply this to web browsing ? Can't each node keep packet

up

Post by Alexandre Guillioud
to 5 seconde based on random ? 5 second isn't a problem, as tor network

is

Post by Alexandre Guillioud
already long to serve pages/packets.
From my point of view, you can't allow some sort of different latency
paths for clients.
It will confuse basics users,
And power users will tweak this to allow only low latency circuits.

Allowing a client to choose their 'delay' and combining low and high
latency networks is (as I understand it) the basis behind Alpha Mixing
[0].
As far as a 5 second window in Tor nodes - off the top of my head, I'm
not sure 5 seconds would really gain anything. If the nodes you're
using (.e.g bridges) aren't used much, 5 seconds doesn't help you. On
the other hand, adding 30 seconds (3 hops, 2 directions) to *each*
request, keeping in mind a page maybe have 20 requests quickly makes
web browsing near-unusuable.
The other elephant in the room is that *even with* high latency, given
*enough* traffic, you can always link it statistically. Think of it
this way: If I'm sending a packet a day to a recipient, you can see a
packet a second leave my machine, and a packet a day received at the
other end. Even if my message is mixed well, held for an hour and
mixed with other messages - it's not hard after a few days to realize
the correlation. High latency makes this harder, harder still if you
don't have a regular pattern. If statistically it's still easy, even
with a 5 second delay, what's the point in making the software harder
to use if you're not getting the defense you seek?
I'm not the authority on Tor's design decisions, but those are my thoughts.
-tom
[0] http://www.freehaven.net/doc/alpha-mixing/alpha-mixing.pdf
_______________________________________________
tor-talk mailing list
tor-talk at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[Paul Syverson]

Post by Tom Ritter
On 9 January 2013 10:05, Alexandre Guillioud

Post by Alexandre Guillioud
Hi all,
I'm reading your conversation, and i'm not understanding very well what you
mean by high/low latency network. Isn't it just a ping duration delta ?
You speak about low and high latency like it's a feature.
Is tor mixing only low latency with low latency in its circuits ? Opening
for a dispatching of services (ie. mail on high latency, web on low ) ?
What's the point ?

Someone can probably explain it better by putting more time into it,
but the gist of it is how long a mix node will 'hold onto' a message,
before sending it on. (Effectively 'mixing' it.)

Post by Alexandre Guillioud
A 'Low Latency' mix network means as soon as a node receives a packet, it sends it out. A 'High Latency' mix network means a node will hold onto a message for some amount of time before sending it out.
Traffic Analysis is a huge part of mix network design. If an
attacker is watching the network (and we generally assume they
are) - how much information do they gain by watching packet paths,
sizes, and times, and how easy is it? If you see a network flow
from Alice to Bob, and Bob to Charlie - those flows will probably
be matchable. With regard to defending against Traffic Analysis,
High Latency is preferable - being able to hold onto a packet for
any length of time before sending it on gives you lot more
options.
Tor is a 'Low Latency' mix network - it has no choice because it's
infeasible to browse the Internet with minute-long (or longer)
delays during page loads. However, email can have delays - if an
email doesn't arrive for 30 minutes or an hour, it's generally not
a problem. So Remailers can afford to be a High Latency mix
network. They will accumulate a number of messages in a pool, and
then when the pool is a certain size, will send the messages
out. There are multiple algorithms for pooling, and we'll go into
more detail about them and pool attacks later.

As a mix node, if I accumulate 8 same-size messages, and then send
them all out at once to 8 recipients, you can't use traffic analysis
to see who I sent which message out to - because they're
indistinguishable. That's high latency. But if I had sent out each
message as soon as I got it, you could see which message went to each
recipient - that's low latency.

Right. Tor isn't mixing at all. Onion routing gets its security from
the observation that even adversaries that can be anywhere typically
can't be everywhere. This is true whether one is trying to protect
properties of the communication between source and remote destination
(typically called anonymity) or protect properties of the
communication between the source and the onion routing network
(typically called circumvention or obfuscation).

Mix network security analysis typically assumes adversaries are on all
links between mixes and at some compromised mixes as well. Tor is
broken against such a model. But, and this is a huge but, while the
above is all correct, it perpetuates the mistaken view that the only
thing going on is a security/practicality tradeoff that mix networks
resolve more in favor of security and onion routing networks resolve
more in favor of practicality. In several important respects Tor is
more secure than any practically deployed, but also practically
deployable mix network. I discuss this more in "Why I'm not an
Entropist" and "Sleeping dogs lie on a bed of onions but wake when
mixed", both available on my webpage (http://www.syverson.org).

That said, I continue to think that combining different latency
traffic as we discussed in the alpha mixing paper mentioned earlier in
this thread can provide real benefit for some applications and
plausible adversaries (although I think what we called 'tau-mixing' in
that paper is the more likely fruitful departure point). But departure
point for someone else: there are years worth of higher-priority-to-me
Tor-related research problems to solve, so it is back-burnered
indefinitely or until somebody entices me that working on this
is worth pulling away from other things.

HTH,
Paul

[adrelanos]

Post by grarpamp

Post by adrelanos
It is an interesting questions, if with a modern user interface, can they
get to new life?

I see no reason the state of the art from the legacy remailer types
can't be combined and updated into a new service running on some
of the same relay machines we have for Tor today. Even if only
10% ran them it would probably be more hosts than were ever
behind the old remailer nets. And relay operators already have the
abuse experience in place.

Do remailer already have exit policies?

Perhaps many Tor relay operators just don't know about high latency
networks but if they knew they were willing to run the software in
parallel to Tor (as non-exit).

Remailers need more up to date documentation and perhaps some improvement
as well. Mixfaster description sounds nice.

https://github.com/cryptodotis/mixfaster