Spy Proof – 3 Keys

Want to be spy-proof? 3 keys to rock-solid encryption

InfoWorld Tech Watch
December 10, 2013

Spy Proof – 3 Keys
How tough is it to put together relatively spy- or hacker-proof cryptography? The devil is in the details
By Serdar Yegulalp | InfoWorld

Want to be spy-proof? 3 keys to rock-solid encryption

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 the TrueCrypt 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.

3. Proper implementation of encryption
In the end, it’s not the algorithm that matters most, but how it’s implemented. To that end, it’s also best not just to rely on someone else’s battle-tested algorithm, but someone else’s battle-tested implementation for same. A well-audited third-party encryption library is always a better choice than rolling your own, and someone else’s well-used encryption container will almost always be better made than the one you hack together.

That said, it isn’t always true that the more broadly used something is, the more widely it’s been scrutinized. The above-mentioned TrueCrypt is a good example: Though it’s one of the most widely implemented third-party disk-encryption systems out there, major questions have lingered about how well it’s put together or whether or not a backdoor of some kind is squirreled away in the code. A third-party auditing fundraiser has since been put together to find out what’s going on, although some preliminary research shows TrueCrypt is probably OK.

What’s toughest of all to determine is whether or not encryption of a remote resource is valid or even taking place. If encryption happens only on the remote server — that is, if it’s not encrypted on the client, then sent — it’s tough to prove anything is happening. Lavabit came under criticism for its implementation of encrypted email, which it claimed didn’t provide anything it hadn’t promised but was still disappointing.

Finally, the biggest problem with any implementation is that it’s only as good as its ultimate implementer: the end-user. A user who pays no attention to the possibility of keyloggers or spyware on their system, both of which can be used to harvest passwords, won’t benefit from any strength of encryption.

In sum, good crypto is akin to a chain: It’s only as strong as its weakest link. As we become more dependent on encryption in most every aspect of our IT-powered lives, every link in that chain deserves the deepest possible scrutiny.

Spy Proof – 3 Keys