- Example Programs and crypttool
- Cryptographic Services and Providers
- Cryptographic Keys
- Encryption and Decryption
- Message Digest
- Message Authentication Code
- Digital Signature
- Key Agreement
- Summary of Cryptographic Operations
- Cryptography with crypttool
- Limited versus Unlimited Cryptography
- Performance of Cryptographic Operations
- Practical Applications
- Legal Issues with Cryptography
- Summary
- Further Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Key Agreement
Secure exchange of data over an insecure channel requires the data packets to be encrypted by the sender and decrypted by the receiver. In such a scenario, one could use symmetric cryptography for encryption and decryption but that would require the communicating parties to use the same secret key. This is not viable for an open communication medium like the Internet that must allow secure exchange among unknown parties without prior agreement to share secret keys.
One might think that public key cryptography is ideally suited to solve this problem. The sender would do the encryption using the public key of the recipient and the recipient would decrypt the message using its own private key. The whole scheme would only require each party to have or generate its own key pair and share the public key with others.
In practice, this approach has a small problem. The performance overhead of public key encryption and decryption is unacceptably high. However, there is a solution to this problem, for the performance issue can be addressed by generating a secret key for encrypting the actual data and encrypting the secret key with the public key. The recipient could now use his or her private key to decrypt the secret key and then use this key to decrypt the data using much faster symmetric decryption.
Even this scheme requires that every entity must have the public key of all other entities with whom it wishes to communicate. This precondition will preclude secure communication between parties that do not know each other beforehand.
One solution is to use the public key cryptography and a key agreement mechanism to agree upon a secret key in such a way that the key itself is never transmitted and cannot be intercepted or deduced from the intercepted traffic. Once such a secret key is agreed upon, it can be used for data encryption and decryption.
J2SE v1.4 supports key agreement operations through the service class javax.crypto.KeyAgreement. We do not get into the programmatic usage details of this class but instead look at one of the key agreement algorithms supported by J2SE v1.4—Diffie-Hellman.
-
The initiator generates a public and private key pair and sends the public key, along with the algorithm specification, to the other party.
-
The other party generates its own public and private key pair using the algorithm specification and sends the public key to the initiator.
-
The initiator generates the secret key using its private key and the other party's public key.
-
The other party also generates the secret key using its private key and the initiator's public key. Diffie-Hellamn algorithm ensures that both parties generate the same secret key.
This sequence of steps is pictorially illustrated in Figure 3-2.
)
Figure 3-2. Diffie-Hellman Key Agreement.
As we see in Chapter 6, Securing the Wire, this mechanism is used by SSL to agree upon a shared secret key and secure the exchange of data.