Unsigned Diffie-Hellman (UDH) Keys

Unsigned Diffie-Hellman (UDH) keys derive their certificate name from the hash of the public key. By communicating the hash over the telephone or some other trusted method of communication with another party, user's can securely communicate without requiring the infrastructure of a CA. How their certificate name is derived and how this is placed in the SKIP packet are shown in Figure B-4.

Figure B-4 Unsigned Diffie-Hellman Keys

The advantages of UDH pairs of public and private keys over signed certificates are as follows:

• The private key is a 256-bit secret that is generated by the user. This secret never leaves the user's machine so there is no longer any need to keep the floppy diskettes containing the certificate locked up somewhere nor to trust that the packages have not been tampered with. All that is necessary is to trust that the user's machine is kept secure.

• Since the private key is always in the user's machine, the physical handling of the key is eliminated so there is no need for a CA and no need to package and ship the private keys.

• Since a key cannot be duplicated and is not registered by a CA, it does not need to be formally revoked; if there is reason to believe a key has been compromised, just generate a new key and repeat the distribution and authentication of your public value and its ID.

• The authentication of the public keys is simplified because it does not have to be done secretly, merely securely.

An example of this last point might be as follows: Two users call each other on the telephone and exchange public keys using the recognition of each other's voice as the authentication mechanism. Because these are hashes of public keys, it does not matter if anyone overhears the conversation.

The disadvantage of UDH keys is that the names must be communicated out of band, such as over the telephone by PGP.

SKIP must be able to name or identify a given key. It does this by using a name or identifier drawn from a namespace identifier (NSID). It also must be able to figure out which certificate name to use when communicating with a remote system. This information can be derived from its IP address or explicitly stated in the protocol via NSID/key ID.

If NSID is set to 0, the IP address is used for key lookup. By default, the NSID is set at 0 and a key ID is not sent; however, with the key ID feature activated, key names are no longer tied to IP addresses. This means that regardless of their physical location on the network or on the Internet, various people have the ability to communicate with each other and corporate using encryption.