Random number generators are important because they play a role in the creation of digital certificates. If the numbers they generate are predictable, or not really random, then it makes it easier to predict organizations' private keys, and thus read any messages encrypted using those keys.

Worse, it makes it more likely that two organizations will generate the same private key. The problem here is that each private key has a unique matching public key, so in theory it is possible for a hacker to trawl a database of public keys, and if any match their own public keys, then they know the private keys match too.

It's an unlikely scenario, but it does show one thing: Encryption is not as strong as we may like to think

Fortunately, there are ways to mitigate some of the known weaknesses associated with encryption. Here are six tips for ensuring that encryption keeps you secure:

Do Not Use Old Encryption Ciphers

Robert Former, senior security consultant for Neohapsis, an Illinois-based security services company, says that organizations should stop using older encryption algorithms like the deprecated DES (Data Encryption Standard), and even its relative Triple DES, which is simply DES applied three times to each data block.

An obvious choice for symmetric encryption is the Advanced Encryption Standard (AES), but whatever the cipher used, there will always be a suspicion about possible NSA involvement in its development.

Former says such fears are probably overstated, however. "In the last 30 years, no one can prove that the NSA did more than influence minor changes in their development. The bottom line is that in most cases the NSA appears to have actually improved the math."

Use Longest Encryption Keys You Can Support

Former recommends organizations use the maximum key lengths possible to make it difficult for those who don't have access to a back door to crack your encryption. "Today AES 128 is strong, but I say go to 512 or the highest key strength you can implement using what you have today," he says.

Encrypt in Layers

Former also recommends making attackers go through as many layers of encryption as possible. "I say if there is a way to encrypt, then encrypt. That means in your database encrypt each field, each table, then the whole database. You have to make it so hard for an attacker that it is not worth the effort," he advises.

Store Encryption Keys Securely

Perhaps the biggest problem organizations face is not the possibility that their encryption algorithms have been backdoored by the NSA, but the fact that the cipher itself is only part of an encryption solution. The other components of the infrastructure, such as key management systems, have to be secure too. Attackers tend to target the weakest point of a security system. Why would an attacker bother trying to crack an encryption algorithm if it is trivially easy to steal the keys?

In some cases organizations leave the keys to the encryption that is protecting their data in the hands of a third party -- particularly when they have data stored in a public cloud and "protected by encryption" by the cloud provider. The problem here is that if you don’t have control of the keys you have to take it on trust that they are being kept secure by the cloud provider's employees.

"If you can implement an encryption system where you control the keys to the data stored in the cloud, then that is going to be much more secure," says Dave Frymier, chief security officer at IT services company Unisys. Devices such as cloud encryption gateways that handle the encryption to and from the cloud automatically can help companies achieve this sort of security.

Ensure Encryption Implementation Is Done Right

"In practice it is very hard to implement an encryption system as it has many moving parts, any one of which can be a weak point," says Ramon Krikken, an analyst at Gartner. "You have to do a great deal of due diligence to make sure that your encryption implementation is done right."

What sorts of things can go wrong in the implementation? Aside from leaving your keys vulnerable, one example Former gives is the way that cipher block chaining (CBC) is implemented. Using cipher block chaining you take a block of plaintext, XOR gate it with a random block of text of the same length called an initialization vector or IV, and then encrypt it to produce a block of ciphertext. The next block of plaintext is then XORed using the previously produced block of ciphertext as the new IV.

Correct implementation of CBC requires a new IV each time the process is started, but that is not always what happens in practice. "A common mistake I see is the implementation of CBC with a static IV that doesn't change. IF CBC is implemented correctly then if I encrypt a block of text on two separate occasions the ciphertext produced will be different," Former says.

Do Not Ignore External Factors

External factors over which companies have very little control can compromise the security of encryption systems. SSL, for example, relies on digital certificates, and these rely in the integrity of the root certificate authorities embedded in browsers such as Internet Explorer, Firefox and Chrome. But how do we know they can be trusted, or that one or more of them is not a front for the NSA or a foreign intelligence (or criminal) organization? Farfetched? Sure, but possible.

And what about DNS, which we rely on when using SSL, but which was never intended to be secure? It's another weak point that that hasn't been fully addressed; as long as DNS can be subverted, attackers can get around encryption using phishing techniques.

Ultimately the message here is that encryption is all about probabilities. A properly implemented encryption system can only be defeated by guessing the key, and the likelihood of being able to do that in a usefully short period of time is not impossible, but still vanishingly small.

Yet poor encryption implementation, the selection of inappropriate ciphers and key lengths, and other factors such as weaknesses in random number generators means that the is not as small as many people imagine.

Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.