This is an old revision of this page, as edited by MBisanz (talk | contribs) at 01:42, 6 August 2005. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Revision as of 01:42, 6 August 2005 by MBisanz (talk | contribs)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)POV in article
- It is important to separate description of the practice of security through obscurity with criticism of it.
- Operators of systems that rely on security by obscurity often keep the fact that their system is broken secret, so as not to destroy confidence in their service or product.
That seems POV to me.
Also, the beginning of the article says that it's a controversial security practice. I thought that it was a pejorative term, and that people who actually practive it call it something else. -- Khym Chanur 07:52, Nov 20, 2003 (UTC)
- Sorry to notice this comment so tardily. The problem noted seems to center around the meaning of 'broken'. Since a cryptosystem is designed to provide security (whichever aspect(s) is the design intent), if it fails to do so, it's broken by the only relevant test -- failure to do as intended. In engineering, an engine breaks when it doesn't work any more; same thing here, in principle. That I don't know about details of the security breach is, I think, irrelevant. You might, and so learn what was to have been securely held, even if he and I remain in pathetic ignorance.
- Thus, I would argue there is no POV around broken in the sentence quoted. ww 15:32, 12 May 2004 (UTC)
security of meaning through obscurity of phrase successful!
I give up. What is meant here by 'their gain'? from article
specifically, many forms of cryptography are so widely known that preventing their gain by a national government would likely be impossible; the RSA algorithm has actually been memorized in detail by most graduating computer science students.
- Maybe specifically, many algorithms are so widely known that preventing any national government from learning them would likely be impossible; the RSA algorithm has actually been memorized in detail by most graduating computer science students. ? — Matt 15:26, 12 May 2004 (UTC)
- Matt, Could be, but this is still seriously incoherent. Needs rephrasing. ww 15:31, 12 May 2004 (UTC)
- Yes, it's poorly worded currently. — Matt 15:35, 12 May 2004 (UTC)
- What about "(they did not change a thing)", that seems a little pointed, maybe something like "Which was not successful" Mbisanz 01:42, August 6, 2005 (UTC)
- Yes, it's poorly worded currently. — Matt 15:35, 12 May 2004 (UTC)
- Matt, Could be, but this is still seriously incoherent. Needs rephrasing. ww 15:31, 12 May 2004 (UTC)
steganography
In looking at the text on the "useless" DMCA, I sense some straying from the topic of this article. I think the point is that systems should use good security rather than just obscurity. Going down the slippery slope to argue about legal and legislative tactics leads to a whole bunch of stuff that dilutes the value of the article, I fear.
Furthermore, I think we need some text on cases where obscurity is in fact good engineering practice - i.e. steganography. And that article needs to refer to this one.... --NealMcB 21:05, 2004 Jul 19 (UTC)
- I think it's fine to mention the DMCA because it's an example of how legislation is used (or is claimed to be used...) to enforce the obscurity of exploits ("security through obscurity") — perfectly on-topic as far as I can see. I agree, however, that the article needs some balance in its treatment; security through obscurity isn't universally bad. Most people running Linux are far safer from attack on the Internet than people running Windows; why? a big component is that Linux is obscure, so there are less viruses, worms and script-kiddies out there that target Linux (and yes, Linux arguably has better intrinsic security). — Matt 02:19, 20 Jul 2004 (UTC)
- The problem with this is that the "obscurity" here is actually more related to confusion about the secret. Cryptographers understand that the secret in a system should be as simple as possible, because this means that you can change it easily, and also that you can study it carefully. So, for example, a users password should be the secret, not their login name. Passwords are easy to change, login names not as easy. When we discuss "obscurity" of OS's (meaning Linux vs. Windows), this is not the same kind of obscurity. In fact, in this context Linux is less obscure, because anyone who wants to can see exactly how each part of the system works. In Windows, the secret is (for example) not only your password, but the software that takes your password and uses it.
- Matt, I would reverse your phrasing. Linux is not arguably more secure than Windows (modulo incompetent configuration), it is so. Having administered both in production environments, my experience is that there is little room for argument on this. Not if you go by the relative amount of effort (and success or lack thereof) in 'securing' them. And it is only arguably due to Linux' relative obscurity -- same reasoning. Linux source is published for all, after all. This is hardly obscurity!!! Incompetence of attacker is not even remotely comparable to attempted intentional obscurity of design.
- As for balance in the article, I think that it's tough to argue that s thru o is sensible in the case of steag while not defensible in the case of poor crypto design. It's an apples and oranges thing. Steag is not design obscurity that some folks are hoping won't be discovered which when lost will allow a successful attack, it's deliberate obsfucation of information upon which depends confidentiality. Not commensurate concepts, really. Comments? Anyone? ww 14:59, 20 Jul 2004 (UTC)
"Advantages and disadvantages of security by obscurity"
That section contains no "Advantages".. Shouldn't this be re-worded?