 the advertised throughput num- bers. If an IPsec accelerator or a security coprocessor can handle multiple algorithms such as Triple- DES and AES, be aware of the extra header bytes that the algorithm may require. Triple DES can require up to 57 extra bytes to be added to a packet, whereas Rijndael/AES with its longer IV require- ments can add up to 65 bytes to the size of an original packet. If the packets used in a throughput test are long enough (longer than 1KB), this extra overhead may be conveniently ignored. If an environ- ment is tested where packets are very short, as is the case in some instances where packets can be as short as 64 bytes, then the extra crypto overhead suddenly occupies half the bandwidth available. Therefore, when speaking about throughput, define exactly what is measured. The wire-speed bit rate, packets per second, and actual cumulative payload (such as the data con- tent of packets after headers and trailers are stripped away) divided over time are all very distinct enti- ties and all denote bit rates. Yet they are somehow usurped concepts that some security chip vendors will not hesitate to use liberally to present a favorable view of their product. It is up to the user to dis- cern the truth. These pointed questions toward a vendor not only formulate a set of expected answers that reflect the environment of a potential user, but they necessarily lead to results that are more meaningful when mapped onto an environment. SSL Acceleration From what we discussed, it should be obvious that SSL performance is more an issue at session setup time. An SSL server has a very different workload from a client device in that case, SO be careful about what is compared. The server first signs its certificate, which it sends to client, and then hashes some pieces of information, which it also sends to the client. Signing euphemism for encrypting something with a private key. In the public-key arena, people usually loosely about encryption when they refer to the operation of encrypting content with