|
Home > Archive > Anonymous Servers > September 2006 > cypherpunk specific remailer throughput
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
cypherpunk specific remailer throughput
|
|
|
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Are there any sources for the current amount of cpunk messages put
through the remailer network? I only found overall numbers in the
'General' section of the Reliable remailer .conf files, e.g. 'Messages
Received Last Week: 50000', which means an average throughput of about
300 messages per hour. But with the easy to recognize cpunk mails
meanwhile becoming a side issue (maybe in the single digit percentage
region?), not much might be left over to mix with, which would mean a
severe security problem for all reply block chains with latencies of
less than several hours. So, are there any type 1 related numbers to
allow a risk assessment?
Sekou
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.panta-rhei.eu.org.
Date: Tue Sep 26 18:43:02 2006 GMT
From: sekou@nym.panta-rhei.eu.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFFGXS6catNh/ vXAo8RAl36AKDPfEaumCmnsE06KmGXj0RJ+0IrNg
Cgnh/L
qZ0Wz7Rt5rMzR1QoWuY2Rec=
=LpNf
-----END PGP SIGNATURE-----
| |
| Deuxpi Admin 2006-09-27, 1:13 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sekou wrote:
> Are there any sources for the current amount of cpunk messages put
> through the remailer network? I only found overall numbers in the
> 'General' section of the Reliable remailer .conf files, e.g. 'Messages
> Received Last Week: 50000', which means an average throughput of about
> 300 messages per hour. But with the easy to recognize cpunk mails
> meanwhile becoming a side issue (maybe in the single digit percentage
> region?), not much might be left over to mix with, which would mean a
> severe security problem for all reply block chains with latencies of
> less than several hours. So, are there any type 1 related numbers to
> allow a risk assessment?
If you take a look at the remailer-conf (or .conf files) of any Mixmaster
remailer, the number of messages is broken in two categories: Mix (Type 2) and
PGP (Type 1.) Thanks to pingers, the Type 1 traffic is still significant (arout
12% on deuxpi.) Also, it seems that there is only a single pool of messages at
the remailer, effectively mixing Type 1 and Type 2 messages.
- --
Deuxpi Admin <deuxpi-admin@deuxpi.ca>
http://www.deuxpi.ca/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFGoEszQ0RLMqB8s4RAu/FAJ45U8gOXXk+eOrqKPh+EaCGPSdFxQCdEoMN
kKEjZhpQ7GNYoMxIffcINaA=
=Z80I
-----END PGP SIGNATURE-----
| |
|
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Deuxpi Admin wrote:
>If you take a look at the remailer-conf (or .conf files) of any Mixmaster
>remailer, the number of messages is broken in two categories: Mix (Type 2) and
>PGP (Type 1.)
Well, I see. Differently from Reliable, which I regarded first,
Mixmaster 2.9.1 (ff.?) remailers hand out those data.
> Thanks to pingers, the Type 1 traffic is still significant (arout
>12% on deuxpi.) Also, it seems that there is only a single pool of messages at
>the remailer, effectively mixing Type 1 and Type 2 messages.
But AFAIK Type 1 and Type 2 messages are different, so that an
adversary observing the remailer i/o would have no problems to
separate the few Type 1 messages from the bunch of Mixmaster mails. In
addition to all other well-known Type 1 disadvantages, that would mean
much better chances to compromise nym users, in particular those with
an email destination :-(
BTW, are the pinger mails you mentioned always (nearly) the same in
size? And don't they only add to the inbound side of the remailer who
has to be pinged (one hop), as the delivery to the pinger happens as
clear text?
Many thanks
Sekou
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.panta-rhei.eu.org.
Date: Wed Sep 27 16:27:48 2006 GMT
From: sekou@nym.panta-rhei.eu.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFFGqaFcatNh/vXAo8RArUtAJ46heJxpFtBvZMIsqrxf140m/ox9ACfRKAR
hq35AB9N8dwhEcq5I5a7ZtY=
=0CV7
-----END PGP SIGNATURE-----
| |
| Deuxpi Admin 2006-09-27, 7:16 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sekou wrote:
> Deuxpi Admin wrote:
>
> But AFAIK Type 1 and Type 2 messages are different, so that an
> adversary observing the remailer i/o would have no problems to
> separate the few Type 1 messages from the bunch of Mixmaster mails. In
> addition to all other well-known Type 1 disadvantages, that would mean
> much better chances to compromise nym users, in particular those with
> an email destination :-(
I think most of the remailers will chain the Type 1 messages to other remailers
by transparently "remixing" them using the Type 2 protocol. Also, with some
luck, the nym server and some remailer will be at the same location. In this
particular case, a nym message could never have to travel on the network as a
Type I message.
> BTW, are the pinger mails you mentioned always (nearly) the same in
> size? And don't they only add to the inbound side of the remailer who
> has to be pinged (one hop), as the delivery to the pinger happens as
> clear text?
- From the echolot pinger configuration documentation:
random_garbage [integer]
Pings usually are quite short. Some 100 bytes are sufficient to
relay all the information that is required. To make them not stand
out that obviously, pings are padded using random garbage of random
length.
random_garbage is the top limit for the amount of bytes to add.
The actual number is randomly generated and uniformly distributed
over [0, random_garbage]
Default: 'random_garbage' => '8192',
As far as I can see, an attacker that can monitor both remailer's incoming and
outgoing traffic cannot make the difference if a particular outgoing message was
coming from a Type I or Type II message. Simply, all messages should be
"remixed" to Type II if the recipient remailer supports it, else Type I with
PGP, or finally plain text if the remailer was the last in the chain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFGuYizQ0RLMqB8s4RAiViAKCBLyfAgJV5
ohsTmOCBddE6m+N0igCeJesB
Cx8awZnAvAIw4qvHNPmZ7/4=
=j4+e
-----END PGP SIGNATURE-----
| |
|
| Deuxpi Admin was so kind to write:
>I think most of the remailers will chain the Type 1 messages to other remailers
>by transparently "remixing" them using the Type 2 protocol. Also, with some
>luck, the nym server and some remailer will be at the same location. In this
>particular case, a nym message could never have to travel on the network as a
>Type I message.
IOW sending Type 1 nym replies through remailers, of which nearly all
are able to remix, doesn't necessarily have to be less secure than
using the Type 2 format right from the start. Such an automatism is
good news and puts my mind at rest.
>
>- From the echolot pinger configuration documentation:
>
>random_garbage [integer]
> Pings usually are quite short. Some 100 bytes are sufficient to
> relay all the information that is required. To make them not stand
> out that obviously, pings are padded using random garbage of random
> length.
>
> random_garbage is the top limit for the amount of bytes to add.
> The actual number is randomly generated and uniformly distributed
> over [0, random_garbage]
>
> Default: 'random_garbage' => '8192',
Thus messages < 8k in (net) size wouldn't be outstanding.
>As far as I can see, an attacker that can monitor both remailer's incoming and
>outgoing traffic cannot make the difference if a particular outgoing message was
>coming from a Type I or Type II message. Simply, all messages should be
>"remixed" to Type II if the recipient remailer supports it, else Type I with
>PGP, or finally plain text if the remailer was the last in the chain.
Many thanks for that valuable information.
Sekou
| |
| Nomen Nescio 2006-09-28, 1:12 pm |
| Sekou wrote:
> Deuxpi Admin was so kind to write:
>
>
> IOW sending Type 1 nym replies through remailers, of which nearly all
> are able to remix, doesn't necessarily have to be less secure than
> using the Type 2 format right from the start. Such an automatism is
> good news and puts my mind at rest.
It shouldn't.
Even with remixing your messages are "pure Type I" messages for a time,
still "landing" on every node in your Type I remailer chain, and
consequently vulnerable to most of the the additional Type I weaknesses.
| |
| Anonyma 2006-09-28, 7:14 pm |
| >> IOW sending Type 1 nym replies through remailers, of which nearly all
>
>It shouldn't.
>
>Even with remixing your messages are "pure Type I" messages for a time,
>still "landing" on every node in your Type I remailer chain, and
>consequently vulnerable to most of the the additional Type I weaknesses.
So what are your recommendations for nym users besides having
sleepless nights?
..
| |
|
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Thu, 28 Sep 2006 17:08:17 -0400 (EDT), Anonyma wrote in
Message-Id: <6da7aa604d93606e3583654f2c5b0c8e@deuxpi.ca>:
> So what are your recommendations for nym users besides having
> sleepless nights?
Try and blend in with everyone else: Don't use features or ciphers that
make your messages look or behave differently to the majority.
Terminate your reply-block at a.a.m rather than an email address.
Type-I is old and does have vulnerabilities. Len Sassaman stated that
it should be considered broken. As there's no alternative to it though,
it's probably best used conservatively.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQEVAwUBRRzh62oLu9HNUqmMAQranQgAiGsymfwB
6I6rix99VrhD95VDn2pY/uZA
xSKi6Tmr8d5vsSUvNrY3nHa/ EZeORw5zBaqosUVPYcmmXHHxORopIFS7U+yW1xVY
oTurJi/OZ2ZZNPGJmoOWy1vHThFe2BWkj2GsCNg/+jfdVMLs3n79G8WJ//ynLrIp
N15nwKZxr6fGEadUr4r3LTRIPgC+2AdwrVP3smq5
/9F8YbkMg0ohlB0nOWEfBCXD
LAo7IggfBI0SqDeKBQZuI3oYD8LOVXAlNO/p+vL88wZicDrrnzo51kTbxPSwH1pp
ofjnZPCaDZ3M+R+o/bRuhCNg6HL4xmfugshe3Trw/8RtP2Nhq8y7zA==
=MrXu
-----END PGP SIGNATURE-----
--
pub 1024D/8ED57743 2003-07-08 Bananasplit Operator
Key fingerprint = 796F 67E0 E890 A0BB BDAE EBB4 94A6 7A09 8ED5 7743
uid Admin <admin.bananasplit.info>
|
|
|
|
|