[Cryptography] Email and IM are ideal candidates for mix networks

Callme Whatiwant nejucomo at gmail.com
Thu Aug 29 15:31:19 EDT 2013


Hello, I'm new here, so I apologize if I'm repeating past arguments or
asking old questions.


On Tue, Aug 27, 2013 at 8:52 PM, Jerry Leichter <leichter at lrw.com> wrote:
>
> On Aug 27, 2013, at 9:48 PM, Perry E. Metzger wrote:
>
>> On Tue, 27 Aug 2013 22:04:22 +0100 "Wendy M. Grossman"
>> <wendyg at pelicancrossing.net> wrote:
>>> On 08/27/2013 18:34, ianG wrote:
>>>> Why do we need the 1980s assumption of being able to send freely
>>>> to everyone, anyway?
>>>
>>> It's clear you're not a journalist or working in any other
>>> profession where you actually need to be able to communicate
>>> spontaneously with strangers.
>>
>> Of course, as a reporter, you are probably getting email addresses of
>> people to talk to via referral, and that could be used to get past the
>> barrier. The problem of people spontaneously contacting a published
>> address is harder.
> Actually, it isn't, or shouldn't be.  Email addresses were originally things you typed into a terminal.  They had to be short, memorable, and easy to type.  "Published" meant "printed on paper", which implied typing the thing back in.
>
> But none of that matters much any more.

This is (anecdotally) completely untrue.

A great way to experience this personally is to start using a
"strange" email address, like mine.  You quickly realize how often you
*say* or *write on paper* your email address.  Because my email
address is "odd", almost every time I say it, the listener asks me to
spell it.  I suspect if I could just say "bob at gmail" I wouldn't
notice how often this occurs.

Now I'm inspired to keep a log of how often I verbally spell an email address.

It would be a grave mistake for us to say: "we're going to help the
typical user, and oh by-the-way, we'll just assume verbally saying
email addresses is not common."  Because if it is, then any solution
based on that assumption will not be adopted, and will therefore not
help the fabled "typical user".

If we went down the road of: "well verbal transmission is rare and
hard, but introductions through cc headers are easy to hook into, so
we'll only support some uses", then we're creating a solution where
users will be easily confused as to the security properties of "an
email address".


> "Publication" is usually on-line, so contact addresses can be arbitrary links.  When we meet in person, we can exchange large numbers of bits between our smartphones.  Hell, even a business card can easily have a QR code on the back.

So I want to highlight something here: "usually" may be accurate, if
we are counting "number of transmissions of email addresses over
time".  Perhaps more and more of that traffic, by volume, is through
automated systems, relieving the burden of users saying, typing, or
otherwise dealing with the string contents.

However, I believe such "email transmissions" are not at all equal in
importance.  For example, if someone just verbally told me their email
address, there's a great chance this is much more important than when
I receive "help at techsupport.example.com" over http by going to my
broken product's website.


>
> Suppose, as in Bitcoin, my email address *is* my public key.  If you wanted to send me email, you'd have a routing problem - but I could even give you hints:  My address would be leichter at lrw.com:<public key>.  You can try there first, or you can look up my public key in some global dictionary.  An attacker could get your mail to me to go to them, but they can't read it - you already know my public key, so only *I* can read it.  The only attack they can mount is a denial of service.  I can have any number of public keys, and all published routes to me may go through a mix - so I can minimize metadata leakage.
>
> The assumption that "initial contact information" has to be something human-processable creates the whole "how do I securely map contact information to a key" problem.  Flip it around and that problem vanishes.

This assumption does *not* create a problem.  The problem exists out
in the world where billions of people use technology based on the
understandings and habits they learned from past experience.

The problem out in the world doesn't vanish no matter what
"simplifying assumptions" we might make on this list.

A counter to my position here is that maybe a solution needn't be used
by everyone initially.  If it's sufficiently usable and has any kind
of networking effect, its use can spread over the population.  I can't
think of any networking effect for privacy or authentication that's
readily apparent to users, and which is backwards compatible with
existing use.  I'd love to hear suggestions though!

Yet another counter is that maybe a solution needn't be used by a
given user in every case, for example by suffixing key material to
addresses in some automatable situations like you suggest..  If the
goal is authenticating human's to one another, this may not be very
successful without massive user education (I'm reminded of http vs
https indicators in browser uis).  If, OTOH, the goal is "as much
resistance to passive surveillance as possible", then maybe partial
coverage, where a user has a hard time making distinctions, is
acceptable on the whole.  (Maybe not for individuals who are bitten by
the confusion, however!)

callme whatiwant


>
>                                                         -- Jerry
>
>>
>> I don't claim to have all the answers, but experimentation will
>> probably tell us a lot more than simply thinking in the abstract.
>>
>> --
>> Perry E. Metzger              perry at piermont.com
>> _______________________________________________
>> The cryptography mailing list
>> cryptography at metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography


More information about the cryptography mailing list