 to RSA but with signifi- cantly shorter keys (an order of magnitude shorter), which translates into bandwidth savings. A quick series of tutorials on fundamentals of ECC can be found at the Certicom web site at www. certicom.com A series of standards have been already compiled using ECC cryptography to imple- ment session key exchanges (such as elliptic-curve-based Diffie-Hellman [EC-DH]) and digital sig- natures (such as EC-DSA, which is the standard elliptic-curve-based Digital Signature Algorithm [EC-DSA]). Both the Institute of Electrical and Electronics Engineers (IEEE) and American National Standards Institute (ANSI) have been actively pursuing standards along several dimensions of these technologies, although many of these technologies (such as Rijndael) have not yet received the IETF's blessing and therefore do not appear in implementations such as IPsec for the moment-a situation that is most likely to change in the not-so-distant future. In general, a designer must weigh the pros and cons between execution speed and security. Longer keys provide higher security, but they take computationally longer to complete. Dedicated security coprocessors do not penalize the main CPU or NPU; therefore, the dilemma goes away. The issue then is to decide how flexible or powerful the security coprocessor is and how easy it will be to interface with the NPU at hand. STANDARDIZED SECURITY PROTOCOLS By now, it should be clear that in order for devices to communicate safely and securely with each other, a series of issues needs to be settled at communication setup time, including the following: Which algorithms will be used among the many that may be implemented inside a system? What will be the session key generation mechanism? What if the other party supports only some but not all the available techniques? How do both parties fall back on a common denominator? What if the parties are able to set up a session according to multiple options? Who gets to decide what will be used and based on what criteria? How will the symm