In Phase 2, the receiver creates a random session key, to be known as "session key B." The receiver exports this key into a key blob, specifying that the sender's key exchange public key be used to encrypt the key blob, and transmits it to the sender.
The receiver then builds up a hash value containing session key A, the receiver's name, session key B, the sender's name, and the text "phase 2." This hash value is then sent to the sending user. The details of this process are discussed in Receiver Code Example.
The data must be hashed in the standard sequence so that the sender will be able to properly validate it. The data formats used by the sender and receiver must also match, although a standard format is not specified here.
The sending user accepts the session key B key blob from the receiver, and imports it into a CSP. The hash value is also received.
The sending user then validates the receiver's hash value by creating a hash of its own containing the same data, and comparing the two hash values. If the hash values do not match, then either the destination user has not been forthright, or someone else is tampering with the data between the two users. In either case, the protocol should be terminated and the communication link severed.
If the two hash values do match, this tells the sender that the receiver is presently online and in real-time communication. This is primarily because the hash value contains session key A, which was sent out encrypted with the receiver's public key. Only the real receiver could have decrypted the session key and built the hash value. Including the human-readable user names in the hash makes it possible to involve the users in the process as an additional check.