If you can do that it seems to me like you could just use symmetric crypto, but I'm really not an expert on this.

> If you can do that it seems to me like you could just use symmetric crypto

No, because with symmetric encryption you'd have to protect the key against theft and tampering (i.e., against reading and writing by a third party), while you only have to protect an asymmetric public key against tampering, which is a lot easier in practice.

(also not an expert, just my understanding of it)

No, in this case you’d still have a private key you’d need to protect.

The private key is on a server you have physical and logical control over. The public key, however, is potentially on millions of consumer devices – some hacker reading out the public key is a question of when, not if.

Asymmetric key exchange is done with a private key on both end points. For things like HTTPS the “client” key is ephemeral. But if you are using the keys for authenticated communication, which I think is what this thread is about, both keys are vital (think: client-side certs).

Let's say you deploy 100 or more IoT devices, and need them to communicate with your server. It's your server, so you can hard code a key in the devices. Now you have two choices:

Choice 1: use a symmetric keys. This means one key per device, which you have to manage. Quite cumbersome. You could instead have one symmetric key for everyone, but then if only one IoT device gets compromised (which over time is a virtual certainty) the whole crypto system would be compromised.

Choice 2: use a public/private key pairs. One for the server, and one for each device. Now the system is only broken when the server key is compromised. If a device gets compromise, the attacker merely learns the server's public key, and can impersonate that particular device.

The main advantage of choice 2 vs choice 1 is that with Choice 2, you can use the same server key for everything. You'd still use a protocol with ephemeral keys, but you wouldn't have to manage many many keys. And if the IoT devices are untrusted (that is, they are assumed compromised or anonymous), the whole system only has to manage one key.

Now sure, you could still make it more performant by retaining symmetric keys around. And you'd have to perform fast key erasure (replacing the key by a hash of the key) from time to time to ensure forward secrecy, but with public keys around the symmetric key can act as a cache, which can safely be erased whenever you restart or update your system.

If I'm following this thread properly, the important difference here is that with symmetric crypto you'd also have to make sure nobody else saw the key. With public keys, it doesn't matter if someone snooped.

I thought Diffie-Hellman key exchange covers the snooping part, at least over the channel.

I guess it doesn't protect against something attacking and snooping on your machine though.

DH by itself protects against passive attackers, but most "snoopers" aren't passive. To securely exchange keys over an untrusted network, you usually want an authenticated key exchange, which is more complicated than DH.

With DH both public keys have effect on the randomness of the shared secret. If the app on the client generates a random DH key-pair for every session, and it uses a public DH value of the server pinned to it, the encryption is authenticated and secure to use.

If there are no public keys pinned to clients (say secure messaging apps like Signal where each user generates their own keys), users need to check the public key fingerprints to make sure there's no MITM attack taking place.

The public key fingerprints that need checking are important because they get introduced in 3DH, which is an AKE. Like 'tptacek mentioned.

At the end of ephemeral DH Bob has successfully agreed a random session key with _somebody_. Maybe Bob hopes it's Alice. No-one else can snoop on their conversation, but the trouble is that neither Bob, nor the other party (which might be Alice) are sure who they're talking to. In particular Mallory might be in the middle having conducted two separate DH agreements one with Alice and one with Bob.

So very likely unless Bob is comfortable with this situation he stills need a mechanism to find out who he's talking to. On the upside he does now have an encrypted channel on which to continue the work.

At scale that only practical answer is an Authority, a Trusted Third Party, people _so_ trustworthy that Alice, Bob and maybe even Mallory agree that they know who is who. In one sense this is so hard it might be impossible. But then again maybe it works anyway?

If you don't need scale, for example maybe you're a conspiracy of a few dozen people trying to bring down the Authority, then you have lots of other options depending on your circumstances including Out of Band verification and the Socialist Millionaires Protocol.

If you are a college kid and convinced that everybody on your Facebook friends list, and everybody on their Facebook friends lists, is a fundamentally good person - but that the Authority is a shadowy conspiracy against you all, you can use the Web of Trust, right up until the guy who once lived with a friend of your cousin's housemate steals your life savings and leaves you in a bathtub filled with ice with a hole where one kidney used to be.