Some people said they are finally adding key transparency features to let you do that, but it should have been there since the start. Something a lot of people already use called SSH literally has had that since forever. It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
If you implement ANY encrypted protocol, key verification is extremely important. If you aren’t verifying keys are possessed only by your recipient, you cannot verify who can read your message.
> It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
SSH/TOFU is one model, PKI is another. Both have their respective merits, especially when combining PKI with certificate transparency.
This is a prerequisite for forward secrecy, which is arguably much more relevant.
> It’s physically impossible to be given the wrong person’s key because you personally had to get them.
Does that matter at all if the (in your threat model non-trustworthy) software just exfiltrates all messages?
If you don't trust your encryption software, it's game over (unless it encrypts everything fully deterministically and you regularly audit its outputs).