librelist archives

« back to archive

Getting enough users

Getting enough users

From:
Jens Kubieziel
Date:
2011-06-14 @ 21:55
Hi,

in your Twitter discussion you also mentioned a number of users and how
to get them. Below are some ideas which can collect more users (from my
point of view). I'm well aware that some may clash with the goals of a
remailer. But maybe they can handled somehow.

1. User interface
   The whole thing has to be usable. Probably the best would be some
   webpage like Anonymouse. A user just enters a To:-address and some
   text and hits Send.

   Furthermore also Tor's browser bundle seems pretty good to me. Just
   unzip it to some place on your hard drive and start it.

2. Possibility to answer
   Usually you'll want to communicate. If there is some possibility to
   answer a received mail I suspect it will collect lots of new users.

3. Usable inside social networks
   From my experience many users don't really use email. Instead they
   switched to Facebook mail (or whatever you may call this). Many young
   people consider email as something old people (we! :) do. I have no
   clue if this can work at all, but when there is some Facebook
   remailer application, I assume it will collect a great number of
   people.

-- 
Jens Kubieziel                                   http://www.kubieziel.de
Das Glück besteht darin, zu leben wie alle Welt und doch wie kein
anderer zu sein. Simone de Beauvoir

Re: [remailer] Getting enough users

From:
Tom Ritter
Date:
2011-06-14 @ 23:27
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>1. User interface
>  The whole thing has to be usable. Probably the best would be some
>  webpage like Anonymouse. A user just enters a To:-address and some
>  text and hits Send.

This idea cropped up earlier, and the argument was 'How can you know
this website is trustworthy?'  Either the crypto happens on the server,
and you have no idea, or the crypto happens in the browser (speaking in
terms of today not what may be implemented in the future) and it's
javascript crypto and can't be trusted.

Not two weeks I argued against javascript crypto.  But I think it can be
'good enough'.  A website that admits its limitations and threat model,
is open, and preferably has a decent reputation behind it, in my
opinion, CAN provide some degree of useful functionality for people to
send anonymous or possibly pseudonymous email.  The technical details
can be debated: self-signed cert people are asked to hardcode vs CA,
open source javascript libraries that are signed and published,
distributed on the site and secondary mechanisms, etc etc.  It won't be
bulletproof, it can be bullet-resistant.  And if you dislike the idea as
a consumer, you can use a client and not the site.

>2. Possibility to answer
>  Usually you'll want to communicate. If there is some possibility to
>  answer a received mail I suspect it will collect lots of new users.

Agree completely.  Mixminion has SURBs, but I haven't played with them.
 Len seemed to have mixed feelings about SURBs recently on twitter, I'm
not sure of his precise thoughts - but I do think that have a
pseudonymous reply-path in addition to anonymous email is very important.

- -tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iEYEARECAAYFAk337lQACgkQJZJIJEzU09uk0gCeM4Sh8YA/pX5rVA8ako6uF2Pf
yroAn2OBG2qKI7FEXIdRC91+7km8gECM
=VmyA
-----END PGP SIGNATURE-----

Re: [remailer] Getting enough users

From:
Nick Mathewson
Date:
2011-06-16 @ 18:00
On Tue, Jun 14, 2011 at 7:27 PM, Tom Ritter <tom@ritter.vg> wrote:
 [...]
>>2. Possibility to answer
>>  Usually you'll want to communicate. If there is some possibility to
>>  answer a received mail I suspect it will collect lots of new users.
>
> Agree completely.  Mixminion has SURBs, but I haven't played with them.
>  Len seemed to have mixed feelings about SURBs recently on twitter, I'm
> not sure of his precise thoughts - but I do think that have a
> pseudonymous reply-path in addition to anonymous email is very important.
>

So I'm not Len, but I'll try to mindread based on past conversations:

The main problem with SURBs isn't SURBs per se; it's with nymserver
designs that use them.  The problem with reply-block based nymservers
is that all messages to a nym are linkable to one another on the input
end, and all messages arriving at a user are linkable to one another
on the output end.  This makes long-term correlation easier than it is
for regular mixnet situations.

I ran some numbers on this for the Pynchon Gate paper; see sections 2
and 4.2 in particular.  4.2 will make more sense if you've also read
"Practical Traffic Analysis: Extending and Resisting Statistical
Disclosure". If those simulations are accurate, then reply-block based
nymservers probably aren't very secure.

yrs,
-- 
Nick

Re: [remailer] Getting enough users

From:
Tom Ritter
Date:
2011-06-21 @ 03:48
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for replying Nick.

> The main problem with SURBs isn't SURBs per se; it's with nymserver
> designs that use them.  The problem with reply-block based nymservers
> is that all messages to a nym are linkable to one another on the input
> end, and all messages arriving at a user are linkable to one another
> on the output end.  This makes long-term correlation easier than it is
> for regular mixnet situations.

> I ran some numbers on this for the Pynchon Gate paper; see sections 2
> and 4.2 in particular.  4.2 will make more sense if you've also read
> "Practical Traffic Analysis: Extending and Resisting Statistical
> Disclosure". If those simulations are accurate, then reply-block based
> nymservers probably aren't very secure.

I looked over those papers.  My first thought was a recipient could
request N bytes of response, and the response would be padded to that.
But that suffers from the problem where an adversary could send N+1 (or
more) bytes to the recipient and the recipient is either (possibly)
prevented from downloading legitimate data, or forced to identify
himself by requesting another N bytes.  If a mathematical sense, I think
that scenario exists *no matter what* against an adversary who can both
observe traffic patterns and introduce messages.  Kind of like a
one-time pad, the only complete solution in an information-theoretic
approach seems to be an infinite pipe moving either legitimate or dummy
data all the time.

The problem is hard... but what if it wasn't approached *soley* in the
purview of mixes?  Instead of being able to identify traffic patterns
between a user and a mix, and seeing how much data is moved - what if
the adversary was forced to do analysis on the amount of data moved
through tor?  If a mix operated off an onion address and (most
importantly) the recipient used tor for more than just mail retrieval
(and of course, the mail retrieval wasn't automated on a timer) - I have
to wonder if the amount of noise introduced makes an attack impractical
for all but the most high-traffic scenarios.  To frustrate reply-path
analysis you have two options: the mixes could move legitimate+dummy
data between themselves outside-tor at a constant rate, or the dummy
data could be dropped and legitimate traffic could be moved through tor.

> We must stop asking whether our anonymity designs can forever defend
> every conceivable sender. Instead, we should attempt to quantify the
> risk: how long our designs can defend which senders against an
> adversary who sees how much.

I agree - I don't think traffic analysis can be solved completely.
Decrypting skype calls or google instant searches are great examples.
But those were scenarios of bare-metal implementations, not attempting
to resist analysis.  Combining the techniques we have, at what volume
does traffic analysis work reliably?  Is a tenth, a hundredth, or a
thousandth of that figure a usable figure?

- -tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iEYEARECAAYFAk4AE70ACgkQJZJIJEzU09sBBgCfQE8tbIfFf2/zJzUK5M9KhvlM
2rIAnRDJgBRnGVw10zc0arLdeAeb7zq/
=WboR
-----END PGP SIGNATURE-----

Re: [remailer] Getting enough users

From:
Nick Mathewson
Date:
2011-06-27 @ 18:45
On Mon, Jun 20, 2011 at 11:48 PM, Tom Ritter <tom@ritter.vg> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks for replying Nick.
>
>> The main problem with SURBs isn't SURBs per se; it's with nymserver
>> designs that use them.  The problem with reply-block based nymservers
>> is that all messages to a nym are linkable to one another on the input
>> end, and all messages arriving at a user are linkable to one another
>> on the output end.  This makes long-term correlation easier than it is
>> for regular mixnet situations.
>
>> I ran some numbers on this for the Pynchon Gate paper; see sections 2
>> and 4.2 in particular.  4.2 will make more sense if you've also read
>> "Practical Traffic Analysis: Extending and Resisting Statistical
>> Disclosure". If those simulations are accurate, then reply-block based
>> nymservers probably aren't very secure.
>
> I looked over those papers.  My first thought was a recipient could
> request N bytes of response, and the response would be padded to that.
> But that suffers from the problem where an adversary could send N+1 (or
> more) bytes to the recipient and the recipient is either (possibly)
> prevented from downloading legitimate data, or forced to identify
> himself by requesting another N bytes.  If a mathematical sense, I think
> that scenario exists *no matter what* against an adversary who can both
> observe traffic patterns and introduce messages.  Kind of like a
> one-time pad, the only complete solution in an information-theoretic
> approach seems to be an infinite pipe moving either legitimate or dummy
> data all the time.

Right.  The never-actually-implemented "Underhill" specification for a
mixminion-based nymserver tried to solve this with server-side
spam-filtering and imap-style operations, so that (if those features
actually worked), it would be hard to make a user actually download an
arbitrary amount of messages.  The pynchon-gate spec, IIRC, has a
feature where if a user receives too many messages to fit in their
allocation, they instead get a summary of the pending messages that
don't fit in their allocation.

> The problem is hard... but what if it wasn't approached *soley* in the
> purview of mixes?  Instead of being able to identify traffic patterns
> between a user and a mix, and seeing how much data is moved - what if
> the adversary was forced to do analysis on the amount of data moved
> through tor?  If a mix operated off an onion address and (most
> importantly) the recipient used tor for more than just mail retrieval
> (and of course, the mail retrieval wasn't automated on a timer) - I have
> to wonder if the amount of noise introduced makes an attack impractical
> for all but the most high-traffic scenarios.

You didn't specify a threat model here, but I don't think that Tor
helps with this one in an obvious way.  The kind of attack that we're
concerned about in high-latency mixnets is generally assumed to be
global, somewhat active, and able to compromise some mixes. Tor (and
similar low-latency systems) don't resist an adversary that can
observe both ends of the communication channel.

-- 
Nick

Re: [remailer] Getting enough users

From:
Jens Kubieziel
Date:
2011-06-27 @ 22:07
* Tom Ritter schrieb am 2011-06-15 um 01:27 Uhr:
> Not two weeks I argued against javascript crypto.  But I think it can be

What were your arguments against and what made you change your mind?

I usually argue against JS crypto, because one needs a secure way to
deploy the code to the client. In most cases this way is a
SSL/TLS-connection. But then the connection is encrypted and to me it
doesn't make sense to send encrypted data over a encrypted line. (very
short version of the argument). But maybe there other/better arguments
in favor of use of JS crypto.

Regards,
-- 
Jens Kubieziel                                   http://www.kubieziel.de
"The three principle virtues of a programmer are Laziness, Impatience, and
Hubris." (Larray Wall)

Re: [remailer] Getting enough users

From:
Meredith L. Patterson
Date:
2011-06-14 @ 22:49
On Tue, Jun 14, 2011 at 4:55 PM, Jens Kubieziel <jens@kubieziel.de> wrote:
> 3. Usable inside social networks
>   From my experience many users don't really use email. Instead they
>   switched to Facebook mail (or whatever you may call this). Many young
>   people consider email as something old people (we! :) do. I have no
>   clue if this can work at all, but when there is some Facebook
>   remailer application, I assume it will collect a great number of
>   people.

It might actually be possible to implement this entirely within the
Facebook API; I forget how much of the messaging functionality is
exposed, but architecturally one could do something similar to the
IPv6 over Facebook implementation that cropped up a few years ago.
"Facebook remops" would have to store their "remailer" keys where
Facebook itself couldn't access them, of course; I'm unsure how much
of a hurdle that presents.

I'll also add 4. Usable on a mobile interface. Fortunately this is not
hard; like your suggested web-interface, just a To: field, some text,
and maybe a Subject field, with an options menu for those who want to
configure some specific sequence of remailers or whatever.

Cheers,
--mlp