It has already been noted that public-key cryptography is unique, and very different from the ordinary secret-key systems that preceded it. This uniqueness creates new pitfalls and new opportunities which this page will discuss.
The basic operation of public-key encryption involves the potential recipient of an encrypted message taking the first step of making his public key available to those who would wish to send secret messages to him.
Viewing this in the abstract, one might think in terms of public keys being posted in a conspicuous public place. In practice, though, this is often not how it happens. Instead, when going to a secured web site where you might enter your credit card number, your browser is sent the public key of the site owner at the same time as it receives the web page to be displayed.
Nothing much would seem to prevent someone from interposing a computer between you and that web site, receiving the web site's public key, and thus receiving the page, and then sending on a copy of it but with its own public key.
Of course, anyone who has used a web browser to visit secure web sites will be familiar with the most common solution that has been adopted to this issue.
Secure web sites send you a signed copy of their public keys; the signature is that of a certificate authority, and the public keys of the certificate authorities are permanently stored in your browser.
While this solution has not turned out to be absolutely perfect in practice, for example because a virus on your computer could rewrite your browser's list of certificate keys, it is a good approach because it is based on a positive verification of keys.
A voice encryption system could protect against a man-in-the-middle attack by having one party read a key checksum to the other party, who would recognize his voice. This method apparently has been used with some military systems.
Recently, a property of cryptosystems called perfect forward secrecy has been seen as desirable.
Messages enciphered in such a system have the property that they cannot be read, even if at some later date one's secret keys are obtained.
How can this be achieved?
The basic technique is simple enough. A genuinely random new public key is generated for each message, and the private key associated with it is discarded after the message has been received and decrypted.
This, however, seems to conflict with the use of certified public keys in order to avoid a man-in-the-middle attack as described above. But the solution is obvious enough; either by encrypting two random values with a key of each type, and using their XOR as the session key, or by encrypting a message twice, once with a key of each type, ensure that both the signed key and the ephemeral key are required to read the message.