The basic idea of using asymmetric cryptography is distributing public keys while keeping the private keys private and using a person's public key to encrypt data sent to this particular individual. This is defined as secure message format. The distribution of public keys can be done in a hierarchical manner (using X.509 certificates) or as a "brotherhood of the ring," establishing the ring of users who share each others' public keys. The last model is used by free privacy-protection software such as PGP and GnuPG. Public key infrastructure (PKI) can be deployed, so that anyone interested can download public keys from the centralized server instead of asking the receiving sides to send them. Such servers can be public (e.g., blackhole.pca.dfn.de and horowitz.surfnet.nl) or privately deployed by your company or organization.

Although the secure message format addresses data confidentiality, it does not provide authentication. This creates a well-documented vulnerability to man-in-the-middle attacks, when an attacker placed between both sides replaces public keys exchanged with his or her own public key. Thus, the attacker can decrypt the data coming from both ends with his or her own private key and forward it to some guy named Bill. At the same time, the attacker can encrypt the decrypted data with public keys of the victims and forward it to its intended destinations. Thus, the attack is completely transparent and the victims would not even suspect that their data has been snooped on. To avoid having Bill read your supposedly secret e-mails, some form of authentication is necessary. That can be done by reversing the process and encrypting the data with your private key. In such a case, anyone with your public key can decrypt and read the data, knowing that the data comes from you and no one else if it was decrypted successfully. This is defined as open message format. Open message format provides nonrepudiation service: An entity is bound to the pair of keys and cannot deny itself as a source of the data sent. The only claim the sending side can make is that the data was modified on the way to the destination. However, we know the method to prove (or disprove) such a claim: one-way hashes. Thus, we can take a one-way hash of the data and encrypt it with the public key before sending it. This is how digital signatures work, providing both nonrepudiation and data integrity services.

Digital signatures carry as much legal weight as conventional signatures, if not more, although the law in your country might be different on this issue; conventional signatures are much easier to forge. To forge a digital signature, the fraudsters must have root-level access to the server that stores the organization's private keys. Thus, such servers must use a stable, secure OS and undergo regular security audits. In some operational systems, commands exist that make the file immutable and undeletable (e.g., chattr +i in Linux). Applying such commands to the private key and then deleting the command binary from the system can confuse some attackers who manage to gain access to the system. It is a good idea to place the private-keys-storing host on a different subnet and implement fascist router access lists, restricting access to the server on a strict "need-to-know" basis. In higher security settings, private keys can be stored on a PDA or laptop kept offline in a durable safe and turned on only when enciphering and signing are necessary. Of course, a removable hard drive or Zip drive or read-only CD can be used for private keys instead of the whole machine; the choice of protection method is yours. Do not forget that the human factor is the weakest link, and only trusted personnel should have access to your private keys. The rest of the employees should not even know how and where the keys are stored.

There are two common digital signature algorithms in use: Digital Signature Algorithm (DSA) and the RSA Signature Scheme. The RSA Signature Scheme is founded on the RSA asymmetric cryptosystem and uses MD5 or SHA-1 for one-way hash generation. It was a de facto standard in digital signature generation and verification before the U.S. government introduced DSA. DSA is based on the ElGamal asymmetric cryptosystem and employs SHA-1. A more secure variety of DSA is the Elliptic Curve DSA (ECDSA). Although (provided the key size is 2,048 bits or higher) both RSA and DSA offer a sufficient level of security, the speed of operations involving both algorithms is different. RSA works much slower when operations involve the private key; the opposite is true for the DSA. Thus, DSA is far more efficient when it comes to signature generation and signing (server side), and RSA is more appropriate for signature verification (client side).

As you probably already realized, although digital signatures provide nonrepudiation and data integrity, no data confidentiality is supplied. A solution for this problem is secure and signed format:

Make sure that:

• The keys are long enough, sufficiently random, and use the full keyspace spectrum.

• Their storage and transmission are secure.

• Key lifetime corresponds to the data sensitivity level.

A secure key backup solution can be both a difficult task and a hard decision to make. We leave it to you, because the key backup saves you from the unfortunate consequences of key loss, but introduces an additional target for private key-hungry intruders.

The question is this: If there is a secure and signed asymmetric cryptography format, why do we still have to use symmetric ciphers?

There are two answers: performance and key size. If the throughput of symmetric ciphers is estimated in megabytes per second, throughput of asymmetric ones is counted in kilobytes per second. The speed of RSA encryption (1,024-bit key) is about 1,500 times slower than the speed of enciphering with any of the five AES finalists. Such performance can introduce unacceptable delays in host and network operation, in particular when wireless networking is involved. Also, even the smallest acceptable 1,024-bit asymmetric cipher keys can be a problem for limited-resource devices like smart cards or mobile phones. Thus, a compromise between asymmetric cryptography secure key exchange and nonrepudiation properties and the performance of symmetric ciphers has to be found. Such a compromise exists in the form of hybrid encryption or digital envelopes:

• Asymmetric keys are used for symmetric key distribution.

• Symmetric keys are used for bulk data encryption.

This model is used in operation of public key cryptographic systems employed by tools like PGP and GnuPG. These tools can use RSA or DSA for asymmetric key generation. A wireless-relevant implementation of GnuPG is its use by the NoCat wireless authentication portal to sign the messages exchanged, thus avoiding the forgery so easily performed on WLANs. When key exchange is implemented in various networking operations, the key agreement is frequently done using the original DH scheme operation based on the discrete logarithms in the finite space calculation problem. The DH standard is outlined in NIST FIPS PUB 186-1 and FIPS 186-2. Common DH key sizes are 768, 1,024, and 2,048 bits. Authenticated DH uses digital signatures to foil man-in-the-middle attacks and has proven to be quite reliable, but slow. ACLs based on the Authenticated DH signatures can be implemented when running IPSec. To address some of the DH cryptosystem drawbacks, the Elliptic Curve DH key exchange scheme was proposed. It has obvious performance and keyspace size advantages over the original DH implementation. Unfortunately, the Elliptic Curve DH key exchange scheme is not currently widely implemented by hardware and software vendors.

On this point we conclude our discussion of asymmetric cryptography and applied cryptography background in general and move to the security protocols and software tools that implement the principles and algorithms we have discussed.