Can obscurity make cryptography better?

Managing security risk is always a cost/benefit trade-off

I often disagree when the so-called experts talk about security in terms of binary decisions. Managing security risk is always a cost/benefit trade-off compared to the value of the thing being protected.

I have always been particularly bothered by security proponents who repeat the mantra, "Security by obscurity is no security," when that declaration is demonstrably incorrect. Obscurity does have value, sometimes significant value, especially in the context of the defense-in-depth paradigm. I've written several articles defending obscurity each year, both here and elsewhere. Even though I can present facts and numbers, and readily demonstrate repeatable experiments to back up my conclusions, my critics usually rely solely on emotional arguments. At the very least, they can never show me how obscurity decreases security without coming up with hyperbolic, unlikely scenarios. A friend shared a popular saying with me: "I can show you the facts, but never convince you."

I was discussing obscurity and crypto with the same friend while we waited hours in an airport. If there is anywhere that obscurity shouldn't apply, it's in cryptography. Crypto needs to be open, tested, and truly secure. But I argue that obscurity can even play a role here. Here are three examples:

Salting password hashes

The clearest example is the salting of password hashes. In most modern authentication databases, the authentication "secret" (password, token, digital certificate, biometric measurement) is usually not stored in plaintext. It is normally obscured using a random or predetermined (based on user's account name or time event, for instance) "salt" value. The salt adds one more wrinkle, that, although trivial in the crypto world, means hackers can't immediately begin cracking hashes into their plaintext equivalents if they have access to the authentication database.

Linux, Unix, and BSD password hashes are often salted with a random value. Although some Microsoft Windows password secrets are salted, the main log-on authentication password hashes (LM and NT) are not. The argument against salting is that in order to collect a Windows password hash, you have to be an administrator, and once you have that, it's pretty much game over already. And while that may be true, any password cracker knows that if you find two password hashes with the same value (which is often the case with shared admin passwords), you can readily and easily see the worth of salts. Salting provides some minor, additional level of obscurity that adds more complications to password cracking.

Hiding crypto

There are instances where hiding the fact that cryptography itself is used can be a good thing. I travel internationally a fair amount. Customs and border control agencies usually have the legal right to inspect my laptop hard drive (a right I don't agree with without a reasonable suspicion that I've committed a crime, but I'm not on the Supreme Courts of these countries).

I often have personal data stored on my laptop, that although not illegal, I'd rather not have unrelated third parties viewing. For instance, why should a customs agent have access to e-mails and letters sent to my wife, or to family vacation pictures? They are private moments not meant to be shared with people I know nothing about.

Join the newsletter!

Error: Please check your email address.

More about LinuxMicrosoftParadigmWikipedia

Show Comments