Java Reference
In-Depth Information
key. Gus would also know that the message wasn't changed en route, either maliciously
by Edgar or unintentionally by buggy software or network noise, because any such
change would have screwed up the decryption. With a little more effort, Angela can
double-encrypt the message, once with her private key, once with Gus's public key, thus
getting all three benefits of privacy, authentication, and integrity.
In practice, public-key encryption is much more CPU-intensive and much slower than
secret-key encryption. Therefore, instead of encrypting the entire transmission with
Gus's public key, Angela encrypts a traditional secret key and sends it to Gus. Gus de‐
crypts it with his private key. Now Angela and Gus both know the secret key, but Edgar
doesn't. Therefore, Gus and Angela can now use faster secret-key encryption to com‐
municate privately without Edgar listening in.
Edgar still has one good attack on this protocol, however. (Important: the attack is on
the protocol used to send and receive messages,
not
on the encryption algorithms used.
This attack does not require Edgar to break Gus and Angela's encryption and is com‐
pletely independent of key length.) Edgar can not only read Gus's public key when he
sends it to Angela, but he can also replace it with his own public key! Then when Angela
thinks she's encrypting a message with Gus's public key, she's really using Edgar's. When
she sends a message to Gus, Edgar intercepts it, decrypts it using his private key, encrypts
it using Gus's public key, and sends it on to Gus. This is called a
man-in-the-middle
attack
. Working alone on an insecure channel, Gus and Angela have no easy way to
protect against this. The solution used in practice is for both Gus and Angela to store
and verify their public keys with a trusted third-party certification authority. Rather
than sending each other their public keys, Gus and Angela retrieve each other's public
key from the certification authority. This scheme still isn't perfect—Edgar may be able
to place himself in between Gus and the certification authority, Angela and the certifi‐
cation authority, and Gus and Angela—but it makes life harder for Edgar.
As this example indicates, the theory and practice of encryption and authentication,
both algorithms and protocols, is a challenging field that's fraught with mines and pitfalls
to surprise the amateur cryptographer. It is much easier to design a bad encryption
algorithm or protocol than a good one. And it's not always obvious which algorithms
and protocols are good and which aren't. Fortunately, you don't have to be a cryptog‐
raphy expert to use strong cryptography in Java network programs. JSSE shields you
from the low-level details of how algorithms are negotiated, keys are exchanged, cor‐
respondents are authenticated, and data is encrypted. JSSE allows you to create sockets
and server sockets that transparently handle the negotiations and encryption necessary
for secure communication. All you have to do is send your data over the same streams
and sockets you're familiar with from previous chapters. The Java Secure Socket Ex‐
tension is divided into four packages:
javax.net.ssl
The abstract classes that define Java's API for secure network communication.
