input (which can be long for a communications session). Then the digital signature algorithm is invoked on the hash itself. As the hash is usually a few bytes long, the process should now take an acceptable amount of time to calculate. At the receiver, it works as follows. The receiver receives information. If it is encrypted, it is decrypted. Then the hash is locally generated from what was received and the signature is verified on the hash. If it is correct (that is, the decrypted hash matches the locally produced one), the informa- tion is accepted as legitimately signed. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. SECURITY COPROCESSORS SECURITY COPROCESSORS 375 Session Key Exchange Public-key cryptography also enables a session key to be easily generated, which can be used by the communicating parties for many different purposes, such as a secure envelope for the secure exchange of the first symmetric key to be used for the content encryption or a mutual seed of pseudorandom LFSR structures to be used in some systems to generate specific random-looking streams as in stream ciphers. The beauty of the session-key idea is that two (or more) parties can engage in a remote handshake protocol to produce it. This takes a maximum of a few seconds in most real-life settings. At the end of the handshake, a common bit sequence has been generated that is essentially impossible for any leavesdropper who monitored the handshake exchanges to guess. This now becomes a common shared secret, which the parties can use in any form and fashion to authenticate themselves to each other. Digital Certificates In the example given in the previous section, when user A signed a message and sent it to user B, if user B was not already in possession of user A's public key KpubA, it would have to retrieve it from server or from some other source. A legitimate fear