× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 4/4/2016 1:52 PM, Nathan Andelin wrote:

Bruce Schneier has a different opinion on obscurity: 'I used to decry
secret security systems as "security by obscurity." I now say it more
strongly: "obscurity means insecurity."'


To put that in proper context, the blogger was citing an x-ray system
employed at airports.

"It runs on the outdated Windows 98 operating system, stores user
credentials in plain text".

Storing credentials in plain text is the antithesis of obscurity. Why is he
calling it security by obscurity? That's another good example of how far
the "security by obscurity" term is being misapplied.

Schneier is a security professional, the author of 'Applied
Cryptography' among other books, papers, and presentations on the topic
of computer security. I myself have been reading him for more than a
decade. Based on my exposure with his writing, I do not personally
believe that Schneier means what you assert he does.

From Schneier's post: 'These are the same sort of problems we saw in
proprietary electronic voting machines, or computerized medical
equipment, or computers in automobiles. Basically, whenever an IT system
is designed and used in secret – either actual secret or simply away
from public scrutiny – the results are pretty awful.'

The proper context is that the airport x-ray scanner was designed in
secret, developed in secret, and deployed in secret, with the thought
that keeping the details secret meant that hackers would not be able to
break it.

If the vendor had released their design for public review, they never
would have used Win98, never would have stored passwords in cleartext,
and in short, never would have deployed such a thing. The context is
not Windows 98, but the secret / proprietary / closed / unvetted
'security process.'

Schneier has spent a lifetime decrying proprietary algorithms. Again,
from the same post: 'Smart security engineers open their systems to
public scrutiny, because that’s how they improve.'

I think the context, the framework that Schneier is working with when he
says that 'obscurity is insecurity' is Kerckhoff's principle, which can
be paraphrased as 'the system should remain secure even if the enemy has
a copy of the algorithm.' Sure, it's fine if you keep the exact
algorithm you choose to use a secret as long as that algorithm has been
tested and vetted in the open by experts.

My point is that an unpublished (obscure) algorithm presents a
significant obstacle for hackers to overcome.

If Schneier were to get together with other top minds in the
cryptography field and design a one-off algorithm to say, allow secure
transmission of nuclear launch codes, and then not publish it, I might
be tempted to agree with this. But Schneier himself would not do such a
thing: he would publish his algorithm and have the entire security
community work on it, crackers and all. I'm not speculating here, he
has actually done exactly that with Blowfish, Twofish, Threefish, and more.

You don't have to give hackers an
opportunity to reverse engineer your code.

Kerckhoff's principle argues that the secret lies in the key, not in the
algorithm. The top minds in the cryptography field agree that
published, vetted algorithms are superior to obscure, unpublished
algorithms. At least, I don't know of any who disagree.

My interest in the field is purely at the hobby level. I read David
Kahn's 'The Codebreakers' when it first came out, and it quite tickled
my fancy.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.