 someone's pub- lic key. In the time rating that vendors typically report to characterize such processes, they quote RSA sign operations per second. 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 394 NETWORK PROCESSORS To start with, this number is not clear at all. In fact, all vendors do not use it similarly: Some manufacturers include the time that their chip takes to produce hashes, in which case some new questions naturally arise: Which hash algorithm was used? How will the performance change if a different hash algorithm were used instead? What will the performance look like without the hashing? Some manufacturers do not include time in the time quotes for these public-key operations to account for hashes because they say that digitally signing takes much more time than producing the hash, SO they argue that it can be neglected (or SO they think). Even if we focus on the RSA encrypt/decrypt operations, which in a digital signature environment directly correspond to the processes of verifying and generating a digital signature, respectively, we will need to know the size of the keys if a hardware-assist unit is used, such as for the CRT calcula- tion. In Table 17.1, where we show some qualitative relationships between operations, we used the term operations to denote the modular exponentiation of the signature generation or verification process. Some vendors talk in terms of sessions per second, transactions per second, keys per second, or exponentiations per second. Some vendors also quote figures for the shorter resume-handshake pro- tocols when they should actually be quoting their performance on the full-fledged SSL session setup handshake. It is therefore critical for a prospective user who is comparing security coprocessors to submit the prospective vendors to the rigors of a thorough questioning SO that no 