Applied Cryptography, Second Edition: Protocols, Algorthms, and Source Code in C (cloth)
(Publisher: John Wiley & Sons, Inc.)
Author(s): Bruce Schneier
Publication Date: 01/01/96
This protocol, first presented in  and corrected in  attempts to counter the suppress-replay attack. It is an enhancement to Yahalom and is an excellent protocol.
- (1) Alice concatenates her name and a random number and sends it to Bob.
- (2) Bob concatenates Alices name, her random number, and a timestamp, and encrypts with the key he shares with Trent. He sends it to Trent along with his name and a new random number.
- (3) Trent generates a random session key. Then he creates two messages. The first is Bobs name, Alices random number, a random session key, and the timestamp, all encrypted with the key he shares with Alice. The second is Alices name, the session key, and the timestamp, all encrypted with the key he shares with Bob. He sends these both to Alice, along with Bobs random number.
- (4) Alice decrypts the message encrypted with her key, extracts K, and confirms that RA has the same value as it did in step (1). Alice sends Bob two messages. The first is the message received from Trent, encrypted with Bobs key. The second is RB, encrypted with the session key.
- (5) Bob decrypts the message encrypted with his key, extracts K, and confirms that TB and RB have the same value they did in step (2).
Assuming both random numbers and the timestamp match, Alice and Bob are convinced of one anothers identity and share a secret key. Synchronized clocks are not required because the timestamp is only relative to Bobs clock; Bob only checks the timestamp he generated himself.
One nice thing about this protocol is that Alice can use the message she received from Trent for subsequent authentication with Bob, within some predetermined time limit. Assume that Alice and Bob completed the above protocol, communicated, and then terminated the connection. Alice and Bob can reauthenticate in three steps, without having to rely on Trent.
- (1) Alice sends Bob the message Trent sent her in step (3) and a new random number.
- (2) Bob sends Alice another new random number, and Alices new random number encrypted in their session key.
- (3) Alice sends Bob his new random number, encrypted in their session key.
The new random numbers prevent replay attacks.
The Distributed Authentication Security Service (DASS) protocols, developed at Digital Equipment Corporation, also provide for mutual authentication and key exchange [604,1519,1518]. Unlike the previous protocols, DASS uses both public-key and symmetric cryptography. Alice and Bob each have a private key. Trent has signed copies of their public keys.
- (1) Alice sends a message to Trent, consisting of Bobs name.
- (2) Trent sends Alice Bobs public key, KB, signed with Trents private key, T. The signed message includes Bobs name.
- (3) Alice verifies Trents signature to confirm that the key she received is actually Bobs public key. She generates a random session key, and a random public-key/private-key key pair: KP. She encrypts a timestamp with K. Then she signs a key lifetime, L, her name, and KP with her private key, KA. Finally, she encrypts K with Bobs public key, and signs it with KP. She sends all of this to Bob.
- (4) Bob sends a message to Trent (this may be a different Trent), consisting of Alices name.
- (5) Trent sends Bob Alices public key, signed in Trents private key. The signed message includes Alices name.
- (6) Bob verifies Trents signature to confirm that the key he received is actually Alices public key. He then verifies Alices signature and recovers KP. He verifies the signature and uses his private key to recover K. Then he decrypts TA to make sure this is a current message.
- (7) If mutual authentication is required, Bob encrypts a new timestamp with K, and sends it to Alice.
- (8) Alice decrypts TB with K to make sure that the message is current.
SPX, a product by DEC, is based on DASS. Additional information can be found in .
[an error occurred while processing this directive]