misunderstandings will occur. The best way to go about doing this is to leave no stones unturned and to insist on figures that show the full-fledged SSL handshake protocol capabilities, where hashes must be calculated, sig- natures must be generated, and signatures must be verified. The result of a performance inquiry with a manufacturer should not just yield a couple of numbers as many vendors would have the users believe. It should produce a three-dimensional matrix of num- bers that will say a lot to the overall systems architect about how a specific coprocessor might work in a new systems design that he or she is trying to sketch out and budget. Last but not least, we need to point out that unfortunately several security coprocessor vendors are not fully prepared to easily share this type of objective detail with customers; therefore, be persistent. SUMMARY In this chapter, we discussed issues related to funtionality of security coprocessors operating in a net- work-processing environment. We looked at the fundamentals of most aspects surrounding private- and public-key cryptographic algorithms and operations as required in communications systems. We also discussed the most commonly used security protocols from a systems standpoint. We explained how to compile elaborate educated lists of criteria that consolidate the best practices of cryptography into ways that allow an individual to probe deeper into vendors' claims in order to identify the substance of a security coprocessor product. Finally, we reviewed the architectures of typical security coprocessors and identified systems engineering techniques of introducing them into larger switch- ing/routing systems next to network processors. We also discussed the trade-offs that are associated with their respective use. 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 S