With most everyone moving to an encrypted-by-default policy, it makes sense to take a close look at how encryption is put together from end to end. How hard is it to create encryption that's genuinely secure and not just providing the illusion of security?
It's tougher to answer this question than it might seem. For one, most attacks on crypto aren't direct campaigns; they involve an end run around the encryption itself or an exploitation of a weakness in its implementation.
Here are three key ingredients to watch for if you want to implement encryption well and keep information from prying eyes, be it government agencies or profiteering cyber criminals.
1. A good algorithm
A good encryption algorithm is hard to find, intentionally so. The process for vetting an encryption algorithm is deliberately long and arduous, since it takes a lot of work and a lot of eyes to determine if a given algorithm can pass muster.
Example: The U.S. NIST (National Institute of Standards and Technology) is only now ending the selection process for a new hash algorithm to replace SHA-3 -- a process that took five years and involved examining some 63 different submissions.
Currently, the AES-256 and Blowfish/Twofish standards are two of the best-understood and most widely implemented algorithms. It isn't hard to make use of them, but you won't want to write your own implementation of them if you can help it, for reasons explored below.
2. Strong random number generation
Encryption algorithms rely on entropy, or random number generation, as a key element. That said,truly random numbers are difficult for computers to generate on their own. Most of the time what you get is described as "pseudo random." If the pattern can be guessed, it's not random anymore, and your encryption is imperiled.
To aid with this, the NIST originally approved a standard -- NIST SP 800-90 -- for generating random numbers for use in encryption. Unfortunately, it's since been alleged that one of the schemes in the standard -- Dual_EC_DRBG -- was subtly compromised by pressure from the NSA in such a way that any program that uses Dual_EC_DRBG as its random number generator is that much weaker to systematic attack.
The easy workaround is not to rely on any one source for your random numbers. Users of theTrueCrypt desktop encryption application will remember that the program requires you to manually generate some random input by moving the mouse around for a period of time -- not a perfect solution, since the user has to intervene, but one that supplies enough entropy to pass muster.
A related brouhaha has blown up recently over the use of hardware-level random number generation. Intel and Via chip sets have instructions that generate random numbers. FreeBSD developers have grown antsy about relying solely on those numbers for encryption and are now "salting" any random numbers provided by them for the sake of additional randomness.
Sign up for CIO Asia eNewsletters.