I have often used TrueCrypt (or other encryption products) to hide my personal data. Now, if the customs agent finds that you use crypto in their search of your laptop, they can legally require that you input your private password to decrypt the data (or you can be prevented from visiting that country for a long time). To avoid this confrontation, I obscure my use of encryption. I rename the desktop shortcut and change its icon. I even rename the involved program files so that they look like temporary text files. I also make sure my encrypted files don't show up in cached areas of recently used documents. The encryption program works just fine when I make my modifications, but the border guards have never found it.

As far as I've been able to research in each of my visited countries, it's not illegal for me to use crypto or to obscure the fact that I use encryption. If asked whether I use encryption software, I will tell the truth, and readily provide the decryption password if requested. I'm not trying to break the law, just protect my privacy.

If the border guards ever get smart enough to run a software scanning program designed to detect the use of crypto, I can always use an executable packer to make their search more difficult. But until they make it against the law to use or obscure the use of my crypto, I'll keep my private data private, thank you very much.

Hiding crypto keys

This last example is more controversial and probably harder to argue technically. Many cryptography software programs have been found susceptible to the Princeton "memory freeze" attack. Without being a crypto expert, I see three key requirements in this exploit. First, that plaintext decryption keys are stored in computer memory. Decryption keys must be in their plaintext equivalents at some point in order for decryption to happen. That's a fact of computer cryptography software unless specialized crypto hardware is involved. Second, that the decryption key can be forced to be semi-permanent in memory, enough to survive a power-off or reboot. Third, that the decryption key can then be located. If any of these traits was not true, then the attack would not work.

We can't easily change the first two facts without using specialized hardware. Who knows, maybe the TPM chip will play more of a role in the future, but for now we are stuck with many software-only solutions. Some vendors are trying to obscure the decryption key in memory so that it cannot be readily distinguished between random noise and what it truly is. Other vendors refuse to attempt to obscure the key, because the practical reality is that no matter how you hide or obscure the key, it eventually has to be converted to plaintext, and that simple truth means that it can always be found, trivially. And if it is a trivial matter to find the key, why try at all? Crypto designers are adverse to designing trivial to defeat defenses.

The answer? Because some vendors are doing it successfully, and like salting, it does add some measure of additional security. It isn't perfect, but it complicates the attack, and others like it. If you're trying to sell your product against a competitor's, and the competitor can say that their product is not readily susceptible to the memory freeze attack, then you're at a competitive disadvantage. And it's not simply a marketing comparison. The obscurity technique does decrease security risk, at least until such a time that attackers change their attack. And even then the vendor can respond. The better, turned around, question is why do nothing when a simple code modification will validly prevent the current attack vector? We do this sort of point-counterpoint defense posturing with almost every other computer defense, incrementally improving the defense when the attacker improves their techniques.

I can think of many more examples when adding obscurity to cryptography adds some additional value. Security is rarely a binary decision and we diminish the discussion when we completely discount the value of obscurity.