There are many cryptographic toolkits to choose from. The final choice may be dictated by your development platform or the algorithm you wish to use. We list a few for your consideration.

JCE and JSSE - Now an integral part of JDK 1.4, the "Java Cryptography Extensions" and the "Java Secure Socket Extensions" are a natural choice if you are developing in Java. According to Javasoft: ``The Java Cryptography Extension (JCE) provides a framework and implementations for encryption, key generation, key agreement and message authentication code algorithms. Support for encryption includes symmetric, asymmetric, block, and stream ciphers. The software also supports secure streams and sealed objects.''

Cryptix - An open source clean-room implementation of the Java Cryptography extensions. Javasoft cannot provide its international customers with an implementation of the JCE because of US export restrictions. Cryptix JCE is being developed to address this problem. Cryptix JCE is a complete clean-room implementation of the official JCE 1.2 API as published by Sun. Cryptix also produce a PGP library for those developers needing to integrate Java applications with PGP systems.

OpenSSL - The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style license, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.

Legion of the Bouncy Castle - Despite its quirky name, The Legion of the Bouncy Castle produce a first rate Java cryptography library for both JSSE and J2ME.

Generating keys is extremely important. If the security of a cryptographic system is reliant on the security of keys then clearly care has to be taken when generating keys.

Cryptographic keys need to be as random as possible so that it is infeasible to reproduce them or predict them. A trusted random number generator is essential.

/dev/(u)random (Linux, FreeBSD, OpenBSD) is a useful source if available.

EGADS provides the same kind of functionality as /dev/random and /dev/urandom on Linux systems, but works on Windows, and as a portable Unix program.

YARROW is a high-performance, high-security, pseudo-random number generator (PRNG) for Windows, Windows NT, and UNIX. It can provide random numbers for a variety of cryptographic applications: encryption, signatures, integrity, etc.

When thinking about key lengths it is all too easy to think ``the bigger, the better''. While a large key will indeed be more difficult to break under most circumstances, the additional overhead in encrypting and decrypting data with large keys may have significant effects on the system. The key needs to be large enough to provide what is referred to as cover time. Cover time is the time the key needs to protect the data. If, for example, you need to send time critical data across the Internet that will be acted upon or rejected with a small time window of, say, a few minutes, even small keys will be able to adequately protect the data. There is little point in protecting data with a key that may take 250 years to be broken, when in reality if the data were decrypted and used it would be out of date and not be accepted by the system anyhow. A good source of current appropriate key lengths can be found at http://www.distributed.net/.