Chosing from the following cryptographic primitives is recommended: RSA with 2048 bit keys and OAEP AES-128 in CBC mode SHA-256 HMAC-SHA-256 HMAC-SHA-1 Other cryptographic algorithms can be used if they are required for interoperability with existing software: RSA with key sizes larger than 1024 and legacy padding AES-192 AES-256 3DES (triple DES, with two or three 56 bit keys) RC4 (but very, very strongly discouraged) SHA-1 HMAC-MD5 These primitives are difficult to use in a secure way. Custom implementation of security protocols should be avoided. For protecting confidentiality and integrity of network transmissions, TLS should be used ().

The following facilities can be used to generate unpredictable and non-repeating values. When these functions are used without special safeguards, each individual rnadom value should be at least 12 bytes long. PK11_GenerateRandom in the NSS library (usable for high data rates) RAND_bytes in the OpenSSL library (usable for high data rates) gnutls_rnd in GNUTLS, with GNUTLS_RND_RANDOM as the first argument (usable for high data rates) java.security.SecureRandom in Java (usable for high data rates) os.urandom in Python Reading from the /dev/urandom character device All these functions should be non-blocking, and they should not wait until physical randomness becomes available. (Some cryptography providers for Java can cause java.security.SecureRandom to block, however.) Those functions which do not obtain all bits directly from /dev/urandom are suitable for high data rates because they do not deplete the system-wide entropy pool. Both RAND_bytes and PK11_GenerateRandom have three-state return values (with conflicting meanings). Careful error checking is required. Please review the documentation when using these functions. Other sources of randomness should be considered predictable. Generating randomness for cryptographic keys in long-term use may need different steps and is best left to cryptographic libraries.