Opportunistic encryption and authentication methods | Hacker News Reader

Opportunistic encryption and authentication methods

moderncrypto.org

35 pointsfrrp14 comments

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?

The funny thing about an MITM is that you can track down where it happens...

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

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.

It is impossible to do dragnet MITM undetected. The probability of a single target validating public keys is low, but if you try MITM`ing every connection, then people will notice the public keys do not match.

Sure, I understand that. I'm saying, what if the NSA just started to MITM all connections, or a large fraction of them? It would be easy to notice that they were doing so, so we would detect that they are doing dragnet surveillance. But we already know they are, so it seems nothing much would change compared to the current situation.

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

Man-in-the-middle is an active attack.

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.

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.

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

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.

> 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...

Or just use tor browser...

Reply on news.ycombinator.com