Cryptography

There is one huge difference between RSA and DH in that the DH algorithm is not used for encryption. Huh? That’s right — DH is not an encryption algorithm; rather, it is a key exchange algorithm. Diffie, Hellman, and Merkle were more concerned with the problem of sharing a key over an insecure channel than they were about the encryption of data, so they came up with a solution that created a way to share a secret.

Here’s how it works:

Natasha has a DH key pair consisting of a private key that she keeps to herself and a public key that she sends to Boris.

Boris receives Natasha’s public key and uses the DH algorithm to create a temporary private key and a temporary public key for himself. (Note that Boris’s keys have something in common with Natasha’s public key.)

Boris now takes his newly created private key and Natasha’s public key and has the DH algorithm generate a secret number.

Boris uses the secret number (instead of a RNG or a PRNG) to generate a key just for this transaction. This is called a session key.

Boris uses the session key to encrypt the data and sends it to Natasha along with his temporary public key.

When Natasha receives the encrypted message she can derive the session key because her keys and Boris’s keys have the same derivative — her public key.

With the session key pulled out of the message, Natasha can now decrypt the message.

Please note that when I say, “Natasha does this,” and “Boris does that,” I really mean that they are using their encryption program to carry out these actions. Natasha’s and Boris’s only real actions are to respond to any dialog boxes that pop up during the process. Of course the encryption program has the DH key exchange algorithm included in it, or none of this would be possible.



Introducing Boris and Natasha
If you’ve ever looked through any other mainstream books on cryptography, you likely noticed that the sender and recipient are usually named Alice and Bob. This was found to be easier then saying “Sender A encrypts a message to give to Recipient B.” There are other characters who play the roles of interceptor, hacker, and trusted third party.

I’ve decided to use Boris and Natasha simply to add some humor to the examples and because they are perfectly cast as characters who might use secret messages. Rocky and Bullwinkle may also appear, so watch for them!
....Don’t Sign Someone’s Public Key Unless You Have Reason To
This pertains to PGP more than anything else. If you were to search for Phil Zimmermann’s key and then look at all the people who have signed his key, the list is enormous. If you talk to Phil, he’ll admit that he has no idea who most of these people are. The only reason you should be signing someone’s public key is either because that person asked you to, or because you are assigning a high level of trust on your own PGP keyring. For heaven’s sake, don’t sign keys for people you don’t know!
...Initialization Vector
Even with good algorithms we need to make sure that there is no way that any messages begin with the same sequence of characters. For example, if every encrypted message began with the characters 234kngaeo9i, it could give an attacker enough information to begin cracking the message.

The trick then, is to make sure that all encrypted messages begin with a unique sequence in the first byte of data. To do that, a sequence of random bytes is appended to the front of the plaintext before encryption by a block cipher, or used as a part of the first step in a block cipher procedure that uses some form of chaining.
...