

Opportunistic encryption and authentication methods - frrp
https://moderncrypto.org/mail-archive/messaging/2014/000767.html

======
vilhelm_s
I wonder how much

> A small number of users performing "stealthy" authentication could protect
> other users by creating uncertainty about which connections can be
> undetectably attacked

is worth in our post-Snowden world. We already know that the governments of
the US, China, Syria, etc, are carrying out pervasive surveillance. They could
just start doing MITM attacks against _every_ connection, and we'd be in the
same situation as we were before implementing opportunistic encryption?

~~~
fiatmoney
That would be expensive. The goal is to generate asymmetric costs.

~~~
tptacek
Be careful what you wish for. NSA's biggest policy goal isn't total awareness
of all information on the Internet. It's _maximizing their budget_.

------
mSparks
Wouldn't protect against passive eavesdropping though would it? They'd just
mim everything

~~~
nightcracker
A passive attack is an attack that can be done without interfering with the
signal.

A MITM attack requires you to hook into the signal and interfere with it,
replacing Alice's and Bob's keys with your own and decrypting/re-encrypting
the communication to keep the illusion up.

So a MITM attack is not a passive attack, but an active one.

~~~
mSparks
Hmmm. I don't see the distinction. They are collecting a ton of data by a
small army of corrupt proxy servers. Without authentication it's just like a
new protocol. And hardly a challenge when we know they are already doing it on
ssl connections.

~~~
pdkl95
You don't see a cost (an/or effort) difference between deploying an army of
trivially simple packet sniffers and and deploying an army of of _stateful_
(RAM requirement), _fast_ (to deep-packet-inspect in realtime) MitM proxies?
That notable difference in cost makes the endeavor worthwhile on it's own, as
long you remember what it buys you (still need real authentication).

A better comparison - which is often ignored in these discussions - is that
the test for something being "useful" doesn't rely only on if it solves
_every_ aspect of the problem. A method should also be compared to the
_current_ situation. For encryption, way too often the current situation is
"still using plaintext". In that situation, even _rot13_ is an improvement
because it require an attacker to take at least some minimal step.

Sometimes you can't solve every part of the problem in one step. Adding an
authentication feature later to improve something that already exists is
probably easier than waiting for a perfect, complete product to happen.

Historically, the crypto community has taken a hard line approach that any
weakness shouldn't be allowed, because they correctly deduce that an attacker
can use any weak link to break past all your security efforts. The result is
we got pgp and everybody still using plaintext. The "all or nothing" attitude
lead to web browsers complaining about self-signed certs when they should be
_automatically_ generated by Apache by default with HTTP retired permanently.
Instead, browsers conflate authentication with encryption and scare people
back to plaintext.

Even if hardware gets so cheap that is zero cost difference between passive
eavesdropping and running a MitM proxy or deep-packet {inspection,injection},
non-authenticated crypto is _still_ worthwhile: it creates a culture where
encryption is normal instead of being seen as suspicious, and it can be an
educational or traditional tool.

//of course, if we _can_ get authentication as well, that would usually be a
better option. Even if we have to wait for "v2.0" to get it

~~~
mSparks
It's not that I disagree, so much as I consider dropping auth completely to be
pretty much a complete waste of time - it solves virtually none if not none of
the problems.

What would be a minimum imho is a "persistence" authentication.

i.e. I don't need to know that Anonymous123 is really joe bloggs of Boston.
What I do need to be reasonably sure of is that Anonymous123 is the same
Anonymous123 that I was talking to last week.

I don't even really care if someone sits and listens in to the conversation -
the weak link in encryption imho is that it isn't anonymous.

And in that context - tor solves most of these problems already.

~~~
rakoo
> it solves virtually none [of the problems]

Consider this: in today's HTTP, the communication between the user and the
server is for everyone to see. With HTTPS, the communication is private
between the user and _a_ server. I believe only the NSA has accurate numbers,
but I guess a whole lot of the servers users are talking to are the correct
one.

Authentication comes _on top of that_ so we can predict this number with more
accuracy. But you may not need to; maybe your conversation really is public,
maybe you don't care. The thing is that we actually _can_ make it so that
everyone can be happy with that: those who expect a minimum of privacy and
those who don't.

We can provide encryption; it's easy and cheap. It doesn't mean the
communication is 100% secure (it never is), but it means it's fare better than
what we have today. We must do it. Again, it doesn't mean communications will
be secure, and browsers should certainly not display unauthenticated encrypted
communications with the reassuring green lock; it means they should show _all_
HTTP connections as completely insecure and unauthenticated HTTPS connections
as mildly secure.

By the way, your model is called Trust On First Use or TOFU [0] and is already
used in some crypto domains, most notably ssh.

[0]
[https://en.wikipedia.org/wiki/User:Dotdotike/Trust_Upon_Firs...](https://en.wikipedia.org/wiki/User:Dotdotike/Trust_Upon_First_Use)

~~~
mSparks
Or just use tor browser...

