Yes, you need some foundational source of trust, but you were going to communicate that public key one way or another. If you don't trust that medium (let's say it's WebPKI TLS and an adversary gets a bad cert from Comodo somehow), the adversary could just lie about the public key too. A MITM adversary that's in a position to unseal and reseal libsodium secretbox messages can also do that with libsodium box.

(For everyone else: just because I'm playing along with this misissuance scenario doesn't mean I don't think ~everyone should trust WebPKI.)

He’s saying that if you can get away with generating something like a random API key and just having the client save that, that’s much safer than using public key cryptography.

Minor clarification:

> that’s much safer than using public key cryptography.

It's much harder to screw up than using PKC (thereby making it safer). It's something that is really important for UX - you want to make the easiest path the safest path.

No. Don't go looking for reasons to use public key where the underlying design doesn't necessitate it.

In a private scenario (i.e. most B2B usage), you can communicate the key through a different channel. One option would be to write it down on a piece of paper, and fly someone to the other business to deliver it. Now both sides have a copy of the key, and transmission is guarded by your trust in your employee to not skim the key.

Mail is another option, depending on how secure you think that is.

It's much safer to just send the public key over whatever medium and then use an authenticated channel to verify the authenticity of said public key.

How often do you have a reliable tamper resistant authenticated channel that isn't also secret?

I might be confident that bad guys won't realise what's going on and somehow break into my email system replacing your public key with their own in, say, six hours it takes to receive and act on the message; whereas I can't be reasonably confident that all my mail systems and all backups of mail systems will remain unbreakable for the foreseeable future or until I've deleted all trace of the symmetric key.

Cryptography is often not about "uncrackable" but about confidence in security over a foreseen interval.

On the 4th of June 1943 the details of Operation Neptune ("D-Day") were a priceless secret of the Allied Command, a break that allowed Berlin to know the plan could have resulted in the invasion force being expected by a heavily prepared and well-reinforced German defence. Those who made it back to England alive would have no reward for their efforts.

By the 7th of June 1943 plans for Neptune were a historical curiosity of little military value.

Good comment, but I couldn't help notice that you got the date (6/6/1944 != 6/4/1943) wrong for Operation Neptune/Overlord: https://en.wikipedia.org/wiki/Operation_Overlord

D'oh. I swear I had the year correct (it's supposed to be a few days before the invasion because the Germans wouldn't be able to respond instantly) in an earlier draft. Thanks for the correction.

And I did mean Neptune, the Overlord plans would have remained valuable for several weeks as they included details of the immediate objectives in Normandy and how resupply would be done, Neptune was just the invasion and related actions.

Establishing a secret key and a secure channel does not require trust. It just requires a pair of keys so that you can be sure that the message gets to the other party unintercepted and unmodified.

However, just because you have a channel that can't be MitM-ed doesn't mean you can actually trust whoever is on the other end. The problem of "how do you know you trust the other end" requires some foundational source of trust, whether that's trusting the transportation medium (that the person you handed the USB key to is actually who he/she claims to be), the issuer (could be yourself), and so on.