> I am not smart enough to make meaningful comments about cryptography, but the expectations from the user to verify things in real life seem the same in both cases.
It pretty much has to be, because it doesn't fall out of any particular crypto algorithm or implementation. When you're setting up an encrypted conversation with some other person, let's say "Bob", how do you ensure that you've actually set it up with Bob, vs. someone pretending to be Bob, or merely forwarding your messages to Bob so that both you & Bob think you're in contact, when you've really got an eavesdropper between you?
In essences, you have to make sure that whatever cryptographic material you've either created or exchanged in order to communicate — e.g., your public keys — are the right ones. (That is, you have actual-Bob's key, not an attackers, and vice versa.) So, you must verify them, in whatever manner will convince you that you've gotten the right key(s). Verifying in person is essentially impossible to fake, unless you believe in masks like those from Mission Impossible.
In this regard, the really important bit is authentication — making sure you're talking to the right person, not just making sure the conversation is private. It does no good to have a private conversation with the wrong person. One might refer to this as the "binding" between the cryptographic key(s) and the real-world meatspace entity (e.g., Bob) those keys represent. Is the binding we have the right binding? And that's the hard problem, it isn't "solvable" in the sense that we can make it invisible, but good UI can help immensely here.
That said, in-person verification isn't the only way you can do things. "Trust-on-first-use" ("TOFU"), which is where you just blindly accept the key during the first conversation, but after that, you expect the same key. The idea being that it's a trade-off between convenience and safety — as long as that first exchange is fine, then afterwards, we'd notice anything fishy. And if you get a different one, there needs to be a reason, like Bob saying "oh I have a new phone now" — but does Bob actually have a new phone (and for some reason couldn't reuse the key from the old phone?) or is someone impersonating Bob using that as an excuse to get you to accept the new key.
Another example is the CA system used by certificates on the web. CA's help establish the binding between a website & its private key by signing certificates. They verify keys, e.g., through the ACME challenges. It's definitely not without its defects, and a fair amount of ink has been spilled over the problems with the CA system. But it again represents a system of figuring out those bindings.
Now, what you should do, e.g., whether TOFU suffices or not, should probably be dictated by some form of threat model. What risks are acceptable to you, what attacks do you expect to see, or that you must guard against (perhaps, e.g., due to legal requirement)? Those will tell you if, e.g., TOFU suffices, or if you need something stronger.
From personal experience, specifically with GPG, just getting someone to display, e.g., a GPG fingerprint, long enough to verify it, is a PITA. It takes all of 15 minutes, but the people I've generally had to do this with are too impatient, and expect it to be simpler and quicker than GPG makes it. Marlinspike's article touches on that sort of stuff in "technological dead end"; although he is mentioning it more from an API integration point of view (which is painful), just day-to-day use of the CLI is also painful, and painful to teach.
It pretty much has to be, because it doesn't fall out of any particular crypto algorithm or implementation. When you're setting up an encrypted conversation with some other person, let's say "Bob", how do you ensure that you've actually set it up with Bob, vs. someone pretending to be Bob, or merely forwarding your messages to Bob so that both you & Bob think you're in contact, when you've really got an eavesdropper between you?
In essences, you have to make sure that whatever cryptographic material you've either created or exchanged in order to communicate — e.g., your public keys — are the right ones. (That is, you have actual-Bob's key, not an attackers, and vice versa.) So, you must verify them, in whatever manner will convince you that you've gotten the right key(s). Verifying in person is essentially impossible to fake, unless you believe in masks like those from Mission Impossible.
In this regard, the really important bit is authentication — making sure you're talking to the right person, not just making sure the conversation is private. It does no good to have a private conversation with the wrong person. One might refer to this as the "binding" between the cryptographic key(s) and the real-world meatspace entity (e.g., Bob) those keys represent. Is the binding we have the right binding? And that's the hard problem, it isn't "solvable" in the sense that we can make it invisible, but good UI can help immensely here.
That said, in-person verification isn't the only way you can do things. "Trust-on-first-use" ("TOFU"), which is where you just blindly accept the key during the first conversation, but after that, you expect the same key. The idea being that it's a trade-off between convenience and safety — as long as that first exchange is fine, then afterwards, we'd notice anything fishy. And if you get a different one, there needs to be a reason, like Bob saying "oh I have a new phone now" — but does Bob actually have a new phone (and for some reason couldn't reuse the key from the old phone?) or is someone impersonating Bob using that as an excuse to get you to accept the new key.
Another example is the CA system used by certificates on the web. CA's help establish the binding between a website & its private key by signing certificates. They verify keys, e.g., through the ACME challenges. It's definitely not without its defects, and a fair amount of ink has been spilled over the problems with the CA system. But it again represents a system of figuring out those bindings.
Now, what you should do, e.g., whether TOFU suffices or not, should probably be dictated by some form of threat model. What risks are acceptable to you, what attacks do you expect to see, or that you must guard against (perhaps, e.g., due to legal requirement)? Those will tell you if, e.g., TOFU suffices, or if you need something stronger.
From personal experience, specifically with GPG, just getting someone to display, e.g., a GPG fingerprint, long enough to verify it, is a PITA. It takes all of 15 minutes, but the people I've generally had to do this with are too impatient, and expect it to be simpler and quicker than GPG makes it. Marlinspike's article touches on that sort of stuff in "technological dead end"; although he is mentioning it more from an API integration point of view (which is painful), just day-to-day use of the CLI is also painful, and painful to teach.