If all of my posts, like this one, and all of my anonymous mail is
TLS'd through Tor to the first remailer in a chain of 20 random
remailers, is there a chance of a snowball in hell of ever tracing
those postings or emails.  Is it as iron clad as iron clad can get?
Is it so anonymnous and secure that one could bet one's life on it?

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

["Followup-To:" header set to alt.privacy.anon-server.]
On Wed, 15 Feb 2006 14:20:07 +0100 (CET), Nomen Nescio wrote in
Message-Id: <260bd4c7a784ee880ab7eecd045db3ee@dizum.com>:

> 	If all of my posts, like this one, and all of my anonymous mail is
> TLS'd through Tor to the first remailer in a chain of 20 random
> remailers, is there a chance of a snowball in hell of ever tracing
> those postings or emails.  Is it as iron clad as iron clad can get?
> Is it so anonymnous and secure that one could bet one's life on it?

If I wanted to send a hugely important message, here's how I would do
it:

1) Make a list of all the remailers that support Ephemeral TLS.
2) Spend a few days injecting dummy messages to those remailers, using
STunnel or equivalent.
3) Send your real message using 6(ish) remailers.  Hardcode the first
and second remailers using those from your TLS list.  Set copies to 2
or 3.
4) Repeat step 2

IMO your method is too complex and differs from the majority of other
messages in too many ways.  It's unusual for messages to traverse 20
remailers, and it's unusual for them to be injected from a Tor node.

The above steps ensure that you have Perfect Forward Secrecy in the
event that remailer keys are compromised in the future.  The dummy
messages help to mask the injection of the real message.  The chain of 6
is strong enough and the message stands a good chance of reaching the
destination without setting copies to something very high that would
stand out.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBQ/ M3rmoLu9HNUqmMAQqB8AgAk3ooRlofZc+t7xFxvz
aJSdnIflp3SaRO
 4xkjptJfseL14jCLitoGfO+7PH8275YE5LLc4PdS
q3gAmp4FSdT/gV6Q4Tr5fmx9
 GbTmjlUG9yl+yDdEFamdMJaHyzg71H0RUD7CUsFR
UCp0C3w0ZT4e3rZJ9Ige2EIJ
 v0jwk5jwhZbRUa+6SEM+evYNqzzJ8yTigWvazG8t
ZyflkBGnxk0DbtHJ17rHsYAm
 MwvOqP7VmVMetbiXTafEkiK+yAMdu3bwMZBRIRnu
c9Lv3FV3W2wSJxX/nG3hfMBh
iGEcHyiKqaJ/ HUPka5HuISf1IluhM0SXmBEPDXwvztpTTuS1NXl5
Ww==
=Anym
-----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>

[ Post a follow-up to this message ]

Nomen Nescio <nobody@dizum.com> wrote in
 news:260bd4c7a784ee880ab7eecd045db3ee@di
zum.com:

>      If all of my posts, like this one, and all of my anonymous mail is
> TLS'd through Tor to the first remailer in a chain of 20 random
> remailers, is there a chance of a snowball in hell of ever tracing
> those postings or emails.  Is it as iron clad as iron clad can get?
> Is it so anonymnous and secure that one could bet one's life on it?
>


Yes, I'm so confident I'd trust your life with it :-)

Actually, no, it's clumsy to the point of being unworkable.  Worse, it is
such an unusual pattern that you have self-selected yourself to stick out
like a sore thumb.

And remember this:  The point where secure communications fail is seldom
the channel - it's more often the endpoints (e.g., no authentication, a key
has been leaked, your machine or the one at the other end is compromised,
the recipient blabs, the style and content of your message gives you away
as the author, etc.).

Regards,

PS  FWIW Osama allegedly uses couriers.

[ Post a follow-up to this message ]

On Wed, 15 Feb 2006 14:20:07 +0100, Nomen Nescio wrote:

> 	If all of my posts, like this one, and all of my anonymous mail is
> TLS'd through Tor to the first remailer in a chain of 20 random remailers,
> is there a chance of a snowball in hell of ever tracing those postings or
> emails.  Is it as iron clad as iron clad can get? Is it so anonymnous and
> secure that one could bet one's life on it?

a tla can see that you downloaded a usenet post and that somebody replied
to it anonymously a day or so later.

they can spot stylistic quirks.

they can tell that you show knowledge of this or that in other posts, and
if you show the same knowledge in posts you want to keep anonymous, you
may have problems.

etc.
~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unknown.  Any address shown in the From header
is unverified.

[ Post a follow-up to this message ]

In article <260bd4c7a784ee880ab7eecd045db3ee@dizum.com>,
nobody@dizum.com says...
> 	If all of my posts, like this one, and all of my anonymous mail is
> TLS'd through Tor to the first remailer in a chain of 20 random
> remailers, is there a chance of a snowball in hell of ever tracing
> those postings or emails.  Is it as iron clad as iron clad can get?
> Is it so anonymnous and secure that one could bet one's life on it?
>
>
If you want the best anonymity that you can get, run a remailer.  That
way you know for sure at least one isn't compromised, and one is all you
need.

/steve
--
The Missing Amendment
The Right To Privacy
http://www.themissingamendment.org

[ Post a follow-up to this message ]

This is a Type III anonymous message, sent to you by the Winston Smith
Project Pboxmix mixminion server at pboxmix.winstonsmith.info. If you
do not want to receive anonymous messages, please contact pbox-
admin@winstonsmith.info. For information about anonymity, see
https://www.winstonsmith.info/pws or
https://e-privacy.firenze.linux.it.

-----BEGIN TYPE III ANONYMOUS MESSAGE-----
Message-type: plaintext

In <dsvd3e$71l$1@bananasplit.info> Zax <fleegle@bananasplit.info> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>["Followup-To:" header set to alt.privacy.anon-server.]
>On Wed, 15 Feb 2006 14:20:07 +0100 (CET), Nomen Nescio wrote in
>Message-Id: <260bd4c7a784ee880ab7eecd045db3ee@dizum.com>:
> 
>
>If I wanted to send a hugely important message, here's how I would do
>it:
>
>1) Make a list of all the remailers that support Ephemeral TLS.
>2) Spend a few days injecting dummy messages to those remailers, using
>   STunnel or equivalent.
>3) Send your real message using 6(ish) remailers.  Hardcode the first
>   and second remailers using those from your TLS list.  Set copies to 2
>   or 3.
>4) Repeat step 2
>
>IMO your method is too complex and differs from the majority of other
>messages in too many ways.  It's unusual for messages to traverse 20

That may be, but it is clearly impossible to know aside from unverifible
claims made by anonymous people.

Is it possible, at any point beyond the injection remailer, to determine how
 many
hops a message has been through or will go through?  Answer: NO

Can you know that there aren't literally thousands of messages sent on
20hop chains every day.  Answer: No

If anyone can answer 'yes' to either of these questions then Mixmaster shoul
d be
considered broken and immediately abandoned as unsafe.

>remailers, and it's unusual for them to be injected from a Tor node.

Thanks to Panta, it's not nearly as unusual as it once was.











-----END TYPE III ANONYMOUS MESSAGE-----

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

["Followup-To:" header set to alt.privacy.anon-server.]
On Wed, 15 Feb 2006 18:02:36 +0100 (CET), nobody@pboxlevel3.homelinux.net wr
ote in
Message-Id: <20060215170236.DE8A2438F1@pboxlevel3.homelinux.net>:
 
>
> That may be, but it is clearly impossible to know aside from unverifible
> claims made by anonymous people.
>
> Is it possible, at any point beyond the injection remailer, to determine h
ow many
> hops a message has been through or will go through?  Answer: NO

It's not possible at any point, including the injection remailer.  My
point wasn't that it's possible to tell how many nodes the message
passes through, just that you lose reliability.  Most people counter
this by sending a large number of copies.  This could make you stand out
because your messages enter the network in bursts.

> Can you know that there aren't literally thousands of messages sent on
> 20hop chains every day.  Answer: No

I know because most people want their messages to arrive.  With the
exception of public forums, it's unlikely that the sender can check his
message reached the destination.  He therefore needs reliability which
means lots of copies.  Lots of copies is IMO not a good thing to do.

> If anyone can answer 'yes' to either of these questions then Mixmaster sho
uld be
> considered broken and immediately abandoned as unsafe.

Mixmaster works correctly in accordance with its specification, it isn't
broken.  It doesn't provide the ultimate in anonymity, in part because it
allows the user too much choice on how to send a message.  In anonymity
terms, choice is bad.

> Thanks to Panta, it's not nearly as unusual as it once was.

Agreed, Panta deserves lots of praise for his work.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBQ/ NkMmoLu9HNUqmMAQobTwgAmU8g6VEnjBMTJ09NoA
IvPCYessLToZMc
 PIV8TKVy4Po+0ZuPGkEXwpV2RVgBCf3IrOHpgMgL
KlATvvXwui+tHleTiuI1s/V5
ACGk/ 4t5IBQuwRAOOrwXLf7AeeieRnLmz+50xtmdOZ4VW
EJlc+K6Gki87voIhu0/
ti70i5eJtSKk7d1QEIwfG6MnVvms/Sr3gY3z/ZBFO7mDaUJDzHOjS4sc7NnxnFK/
LNOU/ ryr5PTtTTr+CNdMfqMdnxoJJaQfCbK7oUhJrmYJy
GDQlQLDH6NFGEJWGiiQ
8pEA8swAu1n9uJgBXc+X/s4evH5dPGrAz1o4iyjgmGRhNtot3uhvJA==
=OofM
-----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>

[ Post a follow-up to this message ]

This is a Type III anonymous message, sent to you by the Mixminion
server at straylight.snikt.net.  If you do not want to receive
anonymous messages, please contact ADMIN.  For more information about
anonymity, see URL.

-----BEGIN TYPE III ANONYMOUS MESSAGE-----
Message-type: plaintext

> is there a chance of a snowball
> in hell of ever tracing those
> postings or emails.  Is it as
> iron clad as iron clad can get?
> Is it so anonymnous and secure
> that one could bet one's life on it?


Regular social interaction sometimes
helps with this condition.

-----END TYPE III ANONYMOUS MESSAGE-----

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zax <fleegle@bananasplit.info> writes:

> It's not possible at any point, including the injection remailer.  My
> point wasn't that it's possible to tell how many nodes the message
> passes through, just that you lose reliability.  Most people counter
> this by sending a large number of copies.  This could make you stand out
> because your messages enter the network in bursts.

NEVER send messages in bursts!  Always send messages with absolutely
monotonous regularity, month in and month out, sending a dummy message
when you have no live one.

Here's the script from stealthmail 0.65 which I published here last
August.  It likely will need modification to run in another setting.

#!/bin/sh

# SYNOPSIS

#    outbeat

# DESCRIPTION

# outbeat : "Output Heartbeat" or "Output Drum-beat"

# Maintain a rigidly periodic sequence of mailings or postings, using
# dummy articles when there are no live ones to send.  The live and
# dummy articles are supposed to be indistinguishable except to an
# intended recipient who has the correct decryption keys.  The effect
# is to conceal live traffic in an ongoing stream of cover traffic, so
# that an observer cannot determine when or how much live traffic is
# being sent.

# The frequency of the output mails is determined by the "mail
# period", which can be set by the user.  Once established, it defines
# an unending sequence of time-slots into the future, to each of which
# will be assigned a mail.  If sending is interrupted for a time,
# perhaps because the Internet connection or the computer itself is
# down, the actual sending frequency is increased when the system
# comes back up, until synchrony is reestablished.  Frequency during
# such catch-up phases is determined by the "catch-up period", which
# is also a user-controlled parameter.

# Notes on choosing the mail period and the catch-up period.  The mail
# period should be short enough to accommodate all live traffic into
# the foreseeable future without unduly delaying any particular mail;
# however, it should be no shorter, to avoid accusations of abuse.
# The catch-up period has to be shorter, and is some compromise between
# making sure catch-up actually occurs often during up-times on the one
# hand, and being open to charges of abuse of the system on the other.

# outbeat is intended to be left running at all times.  However, it is
# reasonably tolerant of restarts, as would be required for example if
# the computer is taken down and rebooted.  It spends most of its time
# asleep.

# outbeat state is maintained in a directory $DIR, which must be
# writable by the user.  On first-ever invocation, outbeat creates the
# necessary files and directories under $DIR.  They are:

# next-slot A small file which always holds the absolute (since epoch)
#           minute-count at which the next unsent mail should be or
#           should have been sent.

# urgent    A Maildir-style mail directory for urgent outgoing mail.

# normal    A Maildir-style mail directory for routine outgoing mail.

# cover     A Maildir-style mail directory for outgoing cover mail.

# See Bernstein's qmail documentation for a description of Maildir
# directories.  A Maildir has subdirectories tmp, new, and cur.  New
# articles can be constructed in tmp and moved to new when completed.
# Because all components of a Maildir are required to be in the same
# file system, such a move is an atomic operation, eliminating mail
# loss or duplication which can result from race conditions.

# urgent, normal, and cover form a priority queue for outgoing mail.
# The user constructs an article in normal/tmp/ or urgent/tmp/, then
# moves it to normal/new/ or urgent/new/.  cover/tmp and cover/new are
# used in a similar way for cover traffic, except that whenever
# cover/new goes empty, this script calls a user-supplied program
# MAKE_COVER, which is supposed to create a new piece of cover traffic
# for use next time it's needed.

# Each time a mail is to be sent, outbeat selects a highest-priority,
# oldest article, sends it, and moves it to the cover/cur directory
# (renaming it to usually prevent clobbering a previous entry there).
# Sent articles all go to the same directory so as to erase record of
# which are live and which are dummy.  (normal/cur and urgent/cur are
# therefore not used, and need not actually exist.)  The user should
# delete old articles from cover/cur/ from time to time, so they don't
# pile up indefinitely.  (They are useful for monitoring and debugging
# outbeat operation.)  The sent article is also touch(1)ed to erase
# its original modification and access times, further obscuring its
# origin.  Note the rename erases the original creation time.

# An article deposited in */new should be complete with headers.  It
# is sent verbatim as standard input to "/usr/lib/sendmail -t", which
# should be implemented even in systems using other than sendmail as
# the MTA (true for example for qmail and smail).

export HOME=/var/lib/stealthmail
PATH="/usr/local/bin:/usr/bin:/bin:/var/lib/stealthmail/bin"
export PATH

# Directory where it all happens
DIR=/var/lib/stealthmail/outbeat
. /etc/stealthmail-conf
# Program to generate cover traffic
MAKE_COVER=/var/lib/stealthmail/bin/make-outbeat-cover

cd $DIR

# The loop is organized to do the right thing during normal, routine
# operation, but also to be somewhat graceful in case of one or more
# restarts during one sleep interval (as might occur while performing
# unrelated system maintenance) and for the one-time initialization.

# Arrange for immediate send unless next-slot is in the future.  If
# this is a restart after a brief interruption, this could crowd
# multiple sends into less than one CATCHUP_PERIOD.  Tough.

WAKEUP_TIME=$(cat next-slot)

while true; do

# Be sure that there's some cover traffic if needed:
if [ "$(ls cover/new/* 2>/dev/null)" == "" ] ; then
$MAKE_COVER $DIR
fi

SLEEPTIME=$(echo $WAKEUP_TIME 60 '*' $(date +%s) - p | dc)
if (( $SLEEPTIME > 0 )) ; then sleep $SLEEPTIME ; fi

# NB: Elapsed real time between here and the "sendmail" invocation
# below is world-visible, and should not be allowed to depend
# significantly on whether the mail to be sent is live or dummy.

# Minutes since 1970 Jan 1 00:00 :
NOW=$(echo $(date +%s) 60 / p | dc)
NEXT_SLOT=$(cat next-slot)

# Bring up the modem link if necessary..  (uses our  own pon)
pon-if outbeat
# Give it a while to come up..
sleep 120

# Reload the configuration
. /etc/stealthmail-conf

if [ -e /var/lock/LCK..modem ] ; then

# Select the highest priority, oldest mail for sending..
SENDING=$(echo $(ls -tr urgent/new/* 2>/dev/null) \
$(ls -tr normal/new/* 2>/dev/null) \
$(ls -tr  cover/new/* 2>/dev/null) \
| cut -d ' ' -f1)

# Use exim's -odqr in order to leave the message for dequeuing
# by the run-mail-queue below.  Otherwise, the queue run in
# run-mail-queue will find the message already being processed
# and return immediately, leading to premature modem hangup if
# the news pull doesn't take enough time.  The "-f '<>'"
# placates the ISP and causes the ISP to supply the sender.

if ( /usr/sbin/exim -odqr -t -f '<>' < $SENDING ) ; then
rm $SENDING
fi

# After a send, the next-slot time is advanced by one period
# regardless of whether the send was on time:

NEXT_SLOT=$(( $NEXT_SLOT + $MAIL_PERIOD ))
echo $NEXT_SLOT > next-slot

# Opportunisticly perform other network activity
if [ ! -f /var/lock/modem-user-pull-aam.lock ] ; then
pon-if pull-aam
/var/lib/stealthmail/bin/pull-aam &
fi
if [ ! -r /var/lock/modem-user-run-mail-queue.lock ] ; then
pon-if run-mail-queue
/var/lib/stealthmail/bin/run-mail-queue &
fi

fi

poff-if outbeat

# The time of our next wake-up call:
if (( $NEXT_SLOT - $NOW < $CATCHUP_PERIOD )) ; then
WAKEUP_TIME=$(( $NOW + $CATCHUP_PERIOD )) ; else
WAKEUP_TIME=$NEXT_SLOT
fi

done

# Implementation notes: Times are expressed in minutes partly because
# this was initially conceived as an "at" script, which uses minutes,
# and partly because seconds-counts since epoch are large enough to
# stress long-integer limitations in some installations.

# "at" was not used because it insists on writing to stderr no matter
# what, and because it doesn't accept simple seconds-since-epoch as
# the time the job should be run.  Stupid translations would be
# required from tick-counts to "civil" time notations, just so at's
# algorithm could apply the reverse translation back to tick-counts
# again.  So instead, one perpetual process is used, which spends most
# of its time sleep(1)ing.

# A down-side of this implementation is that some way has to be found
# to automatically start the job at boot time.  (But to prevent floods
# of outbound mail it should only run while connected to the Internet,
# so it could be started from ip-up.)

# Modified 2004 Nov 11: added "touch $SENDING" to erase original
# create and access times; cleaned up documentation a bit.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>

iD8DBQFD84zpDkU5rhlDCl4RAhXGAJ46G4FoNZ9/u3FxUqqs3c28MGpJ5gCgn+6Y
6LuwU5+TeDaEpLXZtmqBNcg=
=gVjw
-----END PGP SIGNATURE-----

[ Post a follow-up to this message ]

In article <dsvo7i$lgp$1@bananasplit.info>
Zax <fleegle@bananasplit.info> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> ["Followup-To:" header set to alt.privacy.anon-server.]
> On Wed, 15 Feb 2006 18:02:36 +0100 (CET), nobody@pboxlevel3.homelinux.net 
wrote in
> Message-Id: <20060215170236.DE8A2438F1@pboxlevel3.homelinux.net>:
> 
>
> It's not possible at any point, including the injection remailer.  My
> point wasn't that it's possible to tell how many nodes the message
> passes through, just that you lose reliability.  Most people counter
> this by sending a large number of copies.  This could make you stand out
> because your messages enter the network in bursts.
> 
>
> I know because most people want their messages to arrive.  With the
> exception of public forums, it's unlikely that the sender can check his
> message reached the destination.  He therefore needs reliability which
> means lots of copies.  Lots of copies is IMO not a good thing to do.

That depends on how you handle them.

I use 6 to 12 copies in a chain like this:

 *,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,(e
xitremailer)

This results in 6 to 12 chains, with several different injection points.
the copies are NOT all sent at once, instead broken up over several hours.



~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unknown.  Any address shown in the From header
is unverified. You need a valid hashcash token to post to groups other
than alt.test and alt.anonymous.messages. Visit www.panta-rhei.eu.org
for abuse and hashcash info.

[ Post a follow-up to this message ]