Slashdot Mirror
Feature:Obscurity as Security
0 Introduction With the popularity of the open-source mindset, a general contempt has drizzled upon all forms of obscurity. The concept of security through obscurity (STO) in particu lar has been decimated. Security through obscurity, which relies on the ignorance of attackers rather than the strength of defenders, is dead in all but practic e. The victory of the opposing full disclosure approach is so complete that proposed ta ctics die at the mere hint they are a form of STO.
This paper suggests security through obscurity can and does work in certain strictly limited ways, and should not be eliminated unthinkingly from the admin's arsenal. It further implies that the boundaries between STO and 'real' security are blurry and deserve evaluation. However, this paper in no way proposes obscurity as a method for keeping secrets in the long term.
1 Full disclosure does not apply to instantiated data Instantiated data - the data used by specific instances of an algorithm - do not fall within the scope of full disclosure. Were this not so, then even the simplest password would violate the ban on security through obscurity. Passwords are secrets known only to their creators, and password entry is commonly obscured, as in the case of the 'shadow' login of UNIX. While the login protocol may be open, passwords themselves are a form of STO, with obscurity localized in the password string.
Instantiated data are exempt from full disclosure because the risk from their failure is limited. When a script cracks a password, the damage done to the secure system extends only as far as that password's scope. The cracker cannot use the compromised string to gain power directly in another system, even if that system runs the same password protocol. Nor can anything be inferred about the value of one password merely from the value of another with equal or lower permissions.
A similar example of instantiated data obscurity is the private key that forms the basis of asymmetric cryptography. So obscure is this information that it is rare for even the owner to be familiar with its precise value. But such obscurity is a necessary element of modern security schemes. Strong security does not eliminate obscurity - rather, it localizes obscurity to instantiated data. The phrase in cryptology, 'carry all security in the key' might be better phrased 'carry all obscurity in the key'.
2 Full disclosure does not apply to time-limited secrets Secrets that expire after a short lifetime can be protected by a wider array of techniques than long-standing secrets. The defense of information that will be irrelevant in a matter of hours or days may not warrant fully peer-reviewed security. Consider the famous Navajo code-talkers of World War II. Among the Americans coordinating the at tack against Japanese-held islands in the Pacific were a number of Navajo Indians, who spoke a slangy version of the complex Navajo tongue. Commands from HQ were issued through these code-talkers, who encrypted and decrypted with an alacrity that belittled the automated methods of the day. This is an excellent example of time-limited security through obscurity. Secret languages are excellent security in the short-term, but however cryptic Navajo may be, it is a code subject to human betrayal. Use of Navajo against the Japanese much beyond the 3-year window of the war would have been unwise. But because the secrets of American strategy in the Pacific were irrelevant after the conclusion of the fighting, the long-term weakness of obscure Navajo as a security measure was unimportant.
3 Obscurity serves as a tripwire Perhaps the classic example of wrongheaded STO is the administrator who modifies his web server to listen on a nonstandard port - thereby confusing attackers, as the theory goes. Considering the degree to which tasks such as port scanning can be automated, the naivete of this defense seems plain. The cracker might be forced to check all 64512 unreserved ports, but eventually the concealed web server will be found. This appears to be a weakness of STO, but if manipulated correctly, it is in fact a great strength. Imagine that our same admin had also invoked a tripwire script and set it to listen on one or more unused ports. When the tripwire is probed with a SYN packet from a cracker trying to locate the web server, instantly the system goes to full alert. The packet is logged and the admin's pager sounds like an alarm.
Such tripwire approaches work because they do not expect obscurity to keep information hidden. Rather, they obscure information as a ploy to force invaders into showing their hand. Because the obscured implementation differs on each system, crackers must resort to guess-check scanning before attacks can commence. But tripwires are deployed throughout the system, anticipating this very move. Running an automated kit suddenly becomes a risky proposition, and even talented crackers must gamble on, for example, whether 'root' is really the name of the primary account or merely a hotline to the authorities.
Lighthearted implementations of this approach are a staple in the popular "Indiana Jones" films. In one scene, Jones is confronted with a hallway of lettered tiles, all seemingly alike. To cross safely he must step only on those tiles with letters corresponding to the secret word 'Jehovah'. The penalty for a misstep is to crash through the floor and plummet into a gaping pit. Attackers not privy to the password would find an exhaustive search less than optimal in this case. When traps are mingled with genuine data, STO can be a powerful disincentive. Such measures do not make a given machine resistant to breach in the long term, any more than medieval moats could ultimately protect their castles. But like moats, tripwire obscurity provides a critical buffer against attackers, allowing defenders room to breathe.
4 Asymmetric cryptography exhibits traits of STO Despite the notion that asymmetric cryptography such as RSA is 'real' security, in some aspects these methods resemble STO. Indeed, this entire class of cryptography is founded on the hopeful guess that a certain mathematical problem is intractable. The back door into cryptographic methods that rely on multiplying primes is, quite simply, to develop a swift means of factoring those multiples. This NP-time problem must be solved before a private key can b e derived from its corresponding public key, and the notorious difficulty of NP problems leads some supporters to characterize asymmetric cryptography as 'prova bly secure'. This is far from the case - there is uncertainty among mathematicia ns as to whether this problem will even prove non-trivial once approached from t he right angle. Startling progress has been made in solving similar 'impossible' problems using innovative ploys - for example, DNA computers can now solve the Traveling Salesman problem in linear time. Given that asymmetric encryption is used widely in the world's e-commerce infrastructure, the repercussions when this piece of obscurity is cracked are disturbing to contemplate.
One telling argument against STO is that it promotes a false sense of security, leading admins into complacency. But the complexity of asymmetric cryptography, combined with reports of its infallibility, can produce much the same effect. Co nsider this social-engineering exploit of digital signing. Using a tool such as m akecert, the cracker generates a root certificate with the name 'Verisign Class 1 Primary CA' and uses it to sign an end-entity certificate with the subject 'CN=Rob Malda, E=malda@slashdot.org' (CT:Please don't. I'm used to posers pretending to be me in Quake, but not on email ;) The cracker then sends the email to an enemy, using a client that does not validate e-mail addresses and spoofing the return address friendly name. The inexpert recipient, thinking all is in order and knowing that digital signatures never lie, trusts the root certificate and hence forth carries on a conversation with a false CmdrTaco. Only scrutiny of the headers will reveal the mail is actually going to a different address. The widely made claim that public-key cryptography is 'real' security and completely unrelated to 'false' STO delivers a more powerful illusion of security than anything an XOR'd password file can provide.
Even brute-force cryptanalysis has parallels in STO. Suppose we wish to conceal the passwords for a number of Swedish bank accounts. We resolve to write them to a secret location on our hard drive, perhaps a few unused bytes in a file sector. Only we, who know the lucky offset, can read the data. This form of concealment is a typical case of secruity through obscurity. The integrity of our secret depends on the ignorance of the cracker, and a trial of all 2^n possible locatio ns compromises the system. But in what way is this fundamentally different from the 'genuine' security of n-bit encryption? To break this form of security, 2^n keys are generated and tried agains t the cipher text until the result is a plain body. Is the difference between this 'true' security and the 'false' STO merely than n is considerably larger in encryption than in the case of hard drives? But this implies that our real error lay, not in reliance upon obscurity, but in having a hard drive of insufficient size!
5 Conclusions Security in the absence of obscurity is not strictly possible, but good systems both localize and advertise their points of obscurity. When the admin is fully a ware of the obscurity in a system, tripwires and instantiated data can provide a useful complement to more rigorous security techniques. Obscurity cannot keep information safe or concealed for long, but it can make attacks risky and destroy the effectiveness of automatic kits. These benefits should not be dismissed as an article of faith.
Turning off ICMP ping access to a host you want to keep hidden will usually ward off casual script kiddies. In this case, you're obscuring the fact that the machine exists at all.
However, this is always part of a larger overall scheme to keep intruders out.
> DNA computers can now
> solve the Traveling Salesman problem in
> linear time.
The Traveling Salesman Problem is NP-Complete. If the DNA computers are able to solve it in linear time, P = NP, and the most important problem in Computer Science would be solved. I believe you meant: "DNA computers can now solve _some_ instances of the TSP in linear time, which is far different from your previous claim. There are, of course, some algorithms that give you a good approximation to the solution, but they don't "solve" the problem either.
... but it shouldn't be the ONLY security measure.
The criticism of STO is usually directed against systems that use STO as the primary or only security measure.
-- Robert
What a truely afwul set of sentiments... I
The whole concept of STO is based around the idea that your attacker does not know the system that you are using to protect your data.
This is radically different from not knowing a particular piece of information (ie the key) in order to access data.
In the first case an inexpert crypto designer may find that their 'security' system infact contains a large number of clues as to its structure. Take for example a simple substitution cypher, while it might appear to the naked eye to be a random collection letters an experianced attacker would simply build a histogram and break the code based upon the distribution.
Moreover STO can quite easily become an argument for leaving holes (ie possible buffer overflows) open because "nobody knows about it". Quite simply this sort of sentiment has been shown to be very wrong over the years.
I find the arguments about hidden trip wires more interesting - but I would argue that this does not represent STO. The form of security may well be known to the attacker but the actual events which may trigger security alerts could be considered as an equivalent to a key.
STO has had its day - no information which is genuinly important should be protected in this manner.
Given that the normal definition of security is that it should cost the attacker more to breach the defenses than the information itself is worth - information with a very short lifespan may be eligable for some forms of STO and I'm sure that everyone occasionally follows this maxim.
But as a principal and as a technique I would like to see STO burried once and for all.
Tom
First off, the author misunderstands what is meant by STO. It does not mean Security through secrecy. All security depends upon a secret- be it the factorization of a composite, a secret key or password or passphrase, or the combination of a safe. The fundamental security is how difficult is it for an attacker to guess that secret.
So, the logic goes, make it more difficult for the attacker to know what secret they need to guess. Hide the security algorithm from them. Does the safe require a combination, a key, a palm print, or some combination?
The problem is that, by obscuring the implementation, weakness that can signifigantly reduce the amount of secret key the attacker needs to guess are hidden ("Um, it's a bad idea to put the door hinges on the outside of the safe. I don't bother picking the lock- I pop the hinges and simply remove the door.").
And this is the advantage open-source has. It's peer review limits the existance of such backdoors. And fixed faster when they are found.
Do not think for a moment that restricting access to the source code makes it less likely such vulnerabilities will be found. The "black hats" (be they the evil hackers or the evil NSA) always seem to have enough time to reverse engineer the software from the binary. The "white hats" generally have better things to do with their time. By making it harder for the legitimate people to look for security holes, you are simply making it more likely that the people finding the security holes will exploit them, and not announce them. By making it illegal to reverse engineer the products, you're gaurenteeing this.
If you don't beleive me, I recommend Bruce Schneier's "Applied Cryptography".
Really, this article has very little to do with security through obscurity. STO, as implemented by Microsoft, is basically the premise that, because their code is not publicly available, the bugs in it will not be obvious, therefore not easily exploited. Proponents of STO argue that open source systems are more vulnerable because anyone can get the source and find the bugs in it, and thereby exploit these bugs. But the real problem is simply that because the systems which use STO are never as well debugged as their peer-reviewed open-source counterparts, an as-yet-undiscovered bug could be lurking around the next packet. Users must rely on the assurances of vendors, motivated by profit, that their systems are safe; on the other hand the users of open source systems are assured of better quality and quick fixes since the user population is itself selfishly motivated to make the system better and safer.
Granted, this is nothing new, but I thought I'd post something more on topic than the article itself. Stating that encrypted passwords are a form of security through obscurity, as the author does, is just plain silly. If you're going to talk about encryption and STO, it's more relevant to delve into the fact that a closed-source encryption algorithm (a la Clipper) is inherently unsafe because it isn't peer reviewed and therefore has a much greater likelihood of eventually being broken because of the authors' undiscovered mistakes, than does an open-source one which has been examined by a wide audience.
But then, what do you expect...
While this was an interesting article, it wasn't a good defence against STO. The author appears to be arguing that STO, while isn't a good security defence, it can make a good security buffer. These are totally different things. So really he's saying that STO is good to have in your toolbox, it's not a good defence - this is what we've been saying all along.
,hacker Perl another Just)'
Having said that, his arguments are totally bogus. Saying that passwords are obscurity is nonesense. When we speak of STO we're talking about source code, not passwords, keyfiles, etc. Trying to defend STO by talking about the success of the navajo indian code is stupidity in the extreme. There are working practices available _today_ without using STO, so why would anyone bother with a "time limited" crypto?
So just what _was_ this microserf trying to defend? It seems very unclear to me.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I take some exception to the definitions used in the article. Obfuscation of information has never to my knowledge been equated with "security through obfuscation." Equating the two makes makes both terms meaningless.
Security through obfuscation relies on a cracker's ignorance of a system vulnerability for protection, as opposed to disclosing the systems specs and subjecting them to rigorous peer review, allowing the vulnerability to be exposed, analyzed, and fixed.
Encryption is the protection of DATA (whether it is a password, data file, or filesystem) through obfuscation of the DATA. Obfuscating DATA is not the same as obfuscating a system architecture in the hopes no one figures it out. To define the two as the same is no different than defining apples and cucumbers to mean the same thing, and leads to the same meaningless results (an inability to differentiate between the two until new terms are invented to compensate for the obfuscated and undermined definitions of the old words). The desire to not disclose confidential data residing on a hard drive does not imply that one is relying on "security through obfuscation" rather than strong, publicly reviewed security approaches. The two concepts are in many ways completely orthogonal to one another.
About the only thing the article got right is the notion that, if the data need only be protected for a brief time, inherently less secure approaches may be used with some success. What is entirely glossed over, however, is that in using a less secure but perhaps more expedient approach one is still taking a terrible gamble, as there is a greater possibility the data will be compromized earlier than desired than if a more secure approach had been used. The probability may be small because of the limited time frame involved (making the risk "worth it" perhaps) but the possibility is nevertheless quite real. What I do not understand is WHY anyone would want to do something like that, when well documented, secure ways exist for protecting both transient and long term data and systems exist, making that sort of gamble unnecessary to begin with.
The Future of Human Evolution: Autonomy
An excelent article. However, I don't believe your example of a social engineering attack on digital signatures is quite right.
The recipient's email client should check the authority signature of the sender's certificate against the known trusted Verisign certificate. In this case they wouldn't match. You can't make them match unless you know Verisign's private key.
The user will be warned that the identity of the sender could not be verified.
Lachlan.
I'd take objection to his calling the use of NP-complete problems "security through obscurity", specifically his statement that we're depending on the hardness of the problems for security and that they may not be that hard if we approach them right. From what I recall, what we're depending on in reality is the fact that NP-complete problems are harder than any other known problems, and provide an upper bound on the hardness of problems. We don't know that NP-complete problems are neccesarily hard to solve, but we do know that any other problems are easier to solve. Even if someone invents a linear-time method of solving an NP-complete problem they're still harder than any other problems, the upper bound just moved down a lot. This is a problem for cryptography, but it's not solvable without rewriting the rules of mathematics.
As for calling a secret key "security through obscurity", he's missing the point. STO canonically refers to keeping the details of the underlying algorithms and/or implementation unknown. It does not typically refer to the idea that there's some piece of information that a legitimate user possesses that an attacker does not.
... all is in the name of the company.
DO NOT block ICMP ECHO_REQUEST / ECHO_RESPONSE ("ping") packets. If you do, you will confuse systems, such as some routers, which use pings to determine shortest paths. A Net-connected host is required to respond to pings.
Full disclosure does not apply to instantiated data
True, but that's not what we're talking about. We're talking about the code that manipulates that data. Saying that STO doesn't apply to passwords is irrelevant.
Full disclosure does not apply to time-limited secrets
Your example is a time-limited method, not merely a time-limited secret. In context, Navaho was used for a very short time. Expecting to use some encryption method for only a short time and not have it cracked is probably a good example against your argument, rather than for. The Japanese didn't have PentiumIIIs and Linux, so a few years was not much time to work on a crack. Doing something like that today would have the algorithm (new and untested, as per your specs) reverse engineered very shortly. You run the risk of having your messages decrypted in realtime before you stop using that algorithm.
Obscurity serves as a tripwire
This example makes no sense. Such trip approaches work because they detect scans; it has nothing to do with the web server, or what port it's on. I'd be willing to bet that a cracker would be able to complete his scan and root your insecure web server before the sysadmin can respond to the page.
Your Indiana Jones example is bogus: attackers wouldn't exhaustively search. They would intentionally break all the tiles, thus revealing which ones were supported. Crackers are not interested in drama. Not until they break in, anyway.
"STO can be a powerful disincentive" is not true; cracker tools don't care.
"But like moats, tripwire obscurity provides a critical buffer against attackers" is not true, either; tripwire only provides detection.
Asymmetric cryptography exhibits traits of STO
"...quite simply, to develop a swift means of factoring those multiples." Isn't that a direct quote from Bill? I would guess you are not a mathematician. (Neither am I) These methods are believed secure because it is believed there is no such "swift means". In math, that usually means you can't just program around it. It means you cannot do it. DNA computers notwithstanding. My DNA computer can barely play my mp3s, much less decrypt my password.
Incorrectly used crypto programs are also not the issue. The issue is that even "correctly" used STO is insecure.
I am not a cryptographer, nor a mathematician. But even I can see your arguments do not stand up on their own merits.
Saying that some instances can be solved in linear time is meaningless anyway... linear describes the growth of complexity when compared to the size of the dataset - when all you have is a series of points then talking about its complexity is impossible.
I believe he meant to say some subsets (special cases) of the problem can be solved in linear time, which is no big news anyway. For example, the TS problem is easy to solve in linear time in the special case that the graph is a circle.
The question is moot anyway, because the notion that the computer solves the TS problem in "linear time" is correct but deceptive. In Fundamental Algorithms, all CS majors are taught to think of the Theta(N) (order of growth) as the "running time" of an algorithm; they then forget that "running time" is a metaphor for a number of computations. A more correct term for Theta(N) would be "increase in computational resources as input size grows".
A DNA computer uses the chemical and structural properties of DNA to perform an exponential number of calculations in parallel. Thus, it is not computing a linear solution to the Traveling Salesman problem, but merely throwing vastly more computational resources at it. The former is an algorithms problem; the latter is an engineering problem.
(BTW: I suspect that the amount of DNA you need does, in fact, increase exponentially with the data set size but in general this is not a consideration since you can put an insane quantity of DNA in a vat.)
~k.lee
(remove nospam for email)
Can we say that info wants to be free, to obstruct (censor) info is a bug, and to enough eyes all bugs are transparent (routed around)?
If I put my gold in a safe and there's a 1 in 6 billion chance of 'guessing' the combination, that means there's a good chance that SOMEONE on the planet can take it - which brings us to security thru superior firepower.
I want to put my gold in a safe that NOBODY can access except me - perhaps a theoritically impossible goal - in which case all security is
just varying degrees of obscurity but we can put up with infinitesimally small amounts of risk for most practical uses. So the issue may resolve to mere semantics.
But I may be hallucinating again...
Chuck
try { do() || do_not(); } catch (JediException err) { yoda(err); }
1 - Instantiated data
Passwords are the basic means of checking authorization, whether the protocol is obscure or not. I don't see why "password would violate the ban on security through obscurity".
I don't see either how shadow login can be considered an obscure protocol. The author admits himself that the protocol is open. Just because the passwords are hidden does not make the protocol obscure. Using the same logic one may argue that any kind of security system is obscure because it restricts access to data.
2 - time-limited secrets
That is correct. However, this approach is rather risky. You never know how long it will take for attackers to crack it. In fact, it would not be secure to use it more then once...
3 - obscurity as tripwire
OK. I get the point. But how can you connect to a web server if you don't know its port?
Besides, "Such measures do not make a given machine resistant to breach in the long term..."
The author concedes that this tactics can be used to *detect* the attack but not to stop it.
4 - Assymetric encryption
That is his strongest point. Assymetric encryption is indeed a form of security through obscurity. Just imagine what would happen if you find an algorithm to quickly factor large numbers into primes... So yes, he does make his point that any security system cannot be completely free of obscurity.
___
If you think big enough, you'll never have to do it.
Others have pointed this out, but I don't think everyone will get the difference even through they are right, so here is my attempt, dumbed down a bit for the less technical.
Imangine for a moment that I capture Rob (cmdTaco ie founder of /.) and tortue him until he gives me the root password on the main /. server. I now have a seceret, and I can get into /., but I do not have enough information to get into User Friendly Even though(if) both run the same version on linux.
Not imangine that I capture an enginerr from Microsoft and torture him until I get a previously unknown security hole in Windows NT. I can now break into any NT server in the world, (assuming the reqrisites for the hole are in place, obviously a system in a locked room not attached to a netwrok is safe)
See the difference? In one area the terriorist got the ability to break into one machine, in the other the terriorist got the ability to break into virtually any machine.
Now It is possibal that some bug exists in Linux that will allow anyone to get into it. With linux, once I discover how someone got into my machine I can fix it, with NT I have to wait for microsoft. So in reality what makes open source better in the face of attack is that I can fix it in a few hours whereas with STO I have to wait for a vender to fix it. If I'm a minor player and nobody else is attacking me, with STO my vender can leave me in the lurch, whereas with open source I can fix it myself.
Any what do you do if your traps go off? Take the server off line?
There is an old but delightful movie called "How to steal a million" that is based on exactly that scenario. Basically, if your traps go off every fifteen minutes, you will not be paying any attention to them very soon.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Apparently, the author does not understand this significant distinction. Secrecy != obscurity. In this article, "obscurity" is defined so broadly as to be useless... anything that isn't spammed out across the 'net is "obscurity".
In the world of serious computer security, "obscurity" refers to keeping the *mechanism* for storing information secret, not the information itself. In practice, the mechanism should be able to keep the information secret even if the inner workings of the mechanism are known.
For example, the algorithms used in the US government's ill-fated "Clipper chip" were kept secret - security by obscurity. When, under pressure from industry, the algorithms were finally released, significant weaknesses were immediately discovered. RSA, on the other hand, is not obscure. Even having the source code for the actual program used to encrypt data with RSA does not significantly reduce the time required to decrypt it (consider that a PGP-encrypted message states its nature in plaintext, right at the top of the message!)
Another, more MS-vs-OSS example is buffer overflow attacks on daemon programs. The "security through obscurity" approach is to hide the source code, so potential buffer overflows are not obvious. But hiding the source does not *eliminate* them... it just hides them. With patience and educated guesses, they can and will be discovered. By opening the source, potential overflows can be found and discovered. One need look no farther than the recent security reports on the most popular closed-source web server (IIS) and the most popular open-source web server (Apache). Which one has had multiple severe, easily exploitable security holes reported lately? In other words, the obscurity of the IIS source made it harder to find weaknesses, but not impossible. In Apache's case, thousands of eyes have pored over every line of source, and the potential weaknesses were found and eliminated long ago. Which makes you feel safer - code thoroughly studied for weaknesses by thousands of programmers, or code where only the authors have examined it?
---
Hand me that airplane glue and I'll tell you another story.
The problem with STO, where the actual "algorithm" (any steps taken to create that part of your security) is secret, is that you don't know if it is secure.
Because it is not, or hardly (only collegues) peer-reviewed, no one has told you if you made any obvious mistakes, and no one can assign an upper- and lowerbound to the difficulty of breaking your "algorithm".
The algorithm you describe where the admin assigns a different port to the HTTP server is not STO; it can be analyzed, and flaws can be found. (And a great many there are)
There are of course problems with these attempts to use a general concept, such as port numbers here, as a key in a secure protocol.
Probably the biggest is that it is not seen as a secret. If Mr. CFO goes to the companies' secret website at port 6301, employee John Doe can walk in an spot the port number in the web browsers' location bar, because the web browser hadn't thought it was a secret.
Probably Mr. CFO is also an average user who doesn't completely grasp the fact that the URL is now an important secret, so he writes it down on a post-it note attached to his monitor.
The other problem is that "innocent" users, such as search engines, may also scan a whole lot of ports to find a webserver, so a) Mr. Sysadmin will get a lot of false alerts on his pager and b) the information will end up for all to see in some Big Search-engine's Database.
The same goes for Joe Hacker who may be detected but has still taken all the necessary information within 4 seconds.
EJB
sure, don't block ping but even worse don't block ICMP host unreachable as this is used for MTU path discovery and can cause some very wierd errors. (and some frustrated users who have no idea why their transit is screwy) - Matt.
Suppose I hide the exam answers in /home/ebcdic/old/letters. That's STO. But the way you find them is exhaustive search through my directory, just as the way you find my login password is by exhaustive search of character sequences.
The difference of course is the scale of the search. A one character password is no better than an obscure directory.
The important thing is to be able to quantify, or at least make explicit, the effort needed to break in to the system. With prime-product based public key, you can say something like "breaking this requires either solving the discrete log problem or X amount of work using the best known algorithm".
First off, while Priestly does appear to have done some research, apparently he missed researching the definition of "Security Through Obscurity". Large chunks of the article are trying to say STO is essential because you have to keep keys secret. STO refers to systems where algorhithms are kept secret, not keys or data. By extension, if bugs and security holes are kept secret, that too is STO, since it's information about the algorithm. There goes point number 1.
Point number 2 is somewhat valid, if you only need security for a short time, you can get away with STO. However, such situations are rare, and you are just as well off with real security, so why risk STO? Back in WWII, encrypting messages for broadcast was difficult and expensive, so they needed to come up with other ways (Navahos, Enigma, etc.), it no longer is a problem. Speaking of WWII, the German Enigma cypher is a classic example of the utter failure of STO, in a time-limited environment no less.
Point number 3 is not security. Having tripwires in place might be handy against script kiddies, but a well informed hacker can avoid them. Even an uninformed hacker has a statistical chance of avoiding them; just by trying random ports, they might come across the real port before they find any tripwires. Unlike a medieval moat, a digital moat can be just jumped over without any planning or special equipment.
Point number 4 is again based on the just plain wrong "But you keep keys hidden, that's STO" argument, but it makes a few other points as well. Yes, if someone finds a fast way to factor huge products of two primes, public key systems fall apart. Since the best minds in the world have been working on this problem for centuries without finding much, the chance of anyone finding a good solution right away is slim. In the mean time, open, non-STO public key systems with large keys are very secure.
The phony certificate issue is not an issue of "Open Complicated Systems vs STO" it's an issue of "Untrained users can compromise security". Public key systems offer easy ways of protecting against forged certificates, as long as they get used. User training and dillegence is a critical part of any good security system, without it, you don't have security.
The "Swedish Bank Account Number" example isn't an example of STO at all (unless you neglect to mention to anyone that the algorithm is an XOR of a key with the data). It's an issue of key management. On the other hand, using a simple algorithm like XOR would allow a cracker to get some useful information without needing to discover the whole key. More modern security algorithms don't have this hole.
In conclusion, Priestly has shown little understanding of the real issues of security. He has come up with one case where STO is not worse than real security (but also not better), and a bunch of arguments based on misunderstandings that show he should hit some more textbooks.
----
----
Open mind, insert foot.
> To continue my rant, the factoring is not "obscure". RSA would be "obscure" if it relied on some "magic" number - that is, in finding this single "magic" number, one could decode *all* messages encrypted with RSA. Since the public key is, well, public, the strength of the algorithm lies in the difficulty of factoring an arbitrary large composite number that has only 4 factors.
Actually, I think he was referring to the fact that the PRIVATE key must be kept obscure. Naturally. This likens to his issue of passwords being obscure. You can't tell someone your password, or it's useless. Same with RSA. You can't give out your private key, or it's useless.
In any case, yes, I would say that by this definition, ALL security relies on some amount of obscurity. But big deal. This is more or less axiomatic, and the article's point seems to be moot. If that's all he was trying to say, I think it's safe to say we knew that. But that doesn't say that simple obscurity (such as the web page on a different port) is a good bit of security. It's not. It's highly insecure. But it is cheap, isn't it? As in all things, you must evaluate the need along with the price.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
The Clipper algorithm, called "Skipjack", has now been released and cryptoanalyzed by the public cryptography community. Interestingly, it has been found to have possible exploits at 14 rounds, and has exactly 15 rounds. The question of whether the NSA has unknown technologies capable of breaking it at full strength is unanswerable, but suspicions are that the answer is "yes". But it currently cannot be broken via publically-available means.
-E
Send mail here if you want to reach me.
One of the remarkably few papers presented by Microsoft at this year's Siggraph conference was on watermarking of models. The idea of watermarking, of course, is to embed some signature of the creator of the actor/model/whatever in the object itself, in a way that is robust. Hughes Hoppe, along with Emil Praun and Adam Finkelstein of Princeton, did indeed come up with a way of doing so that is all those things, by copying (extending? embracing?) a technique from the audio and image watermarking body of knowledge -- he encoded the watermark in the most salient features of the model, at various frequencies. The author of the model saves the original model, the watermark parameters, and releases the watermarked model to the customer. An interesting part of this, though, is that the watermarking algorithm -- or in this case -- the parameters passed to the algorithm, must be secret or it would be trivial to defeat. Furthermore, there is an interesting question when it comes to proving that someone has stolen the model. The original author must produce both the original model, and the watermark algorithm, to verify to the rest of the world that the suspect model is indeed a copy. Now, I would expect Microsoft (say) to object to this -- because if they release the details of the algorithm then anybody could defeat it. On the other hand, are you going to trust the alleged owner of the original when he says "Oh yes, the watermark demonstrates that it's my model. I'm sorry, but I cannot prove this to you." Even if they do that, it is difficult (though not impossible) to conceive of a watermarking system that doesn't allow post-hoc watermarking; that is, generation of a 'original' from the suspect copy. Hoppe does note this in his article, but it's just in passing. Finally, for you other Microsoft-haters out there, in Future Work Hoppe includes "an automated agent such as a web crawler to search for possible stolen watermarked documents." Here's the article
I love Mondays. On a Monday, anything is possible.
Reality is that there exist encryption algorithms whose output could only be decrypted if a) you have the key, or b) you have the mythical quantum computers. With current technology, using a large key with a modern algorithm like TwoFish is pretty much unbreakable. Even with technology envisionable for the next twenty years it will remain unbreakable.
Public key (asymetrical) encryption is theoretically breakable via mathematical attacks, i.e., that a quantum leap in our knowledge of mathematics could render it worthless. That is because the two keys are mathematically related. There are algorithms available now that are stronger for a given key length than the popular NSA-backed RSA algorithm (see 'eliptical curve technology' for an example), but those simply use a different function to feed the primes into. One reason to use an asymetrical algorithm only to exchange the keys for a symetrical algorithm is that this reduces the amount of text transmitted via the algorithm and thus presumably gives less ability to break it.
In reality, when faced with a 1024-bit key and a modern encryption algorithm, you're not going to decrypt it without the key. But of course there's always side-channel attacks. If you have physical access to one end of the system to be cracked, for example, you can always just "look over the guy's shoulder" as he types in the password unlocking his keychain and reads the decrypted text. This could be via electronic surveillance literally looking over his shoulder, this could be via sneaking a virus into his system that records his keystrokes and records bitstreams coming to and from the hard drive and floppy drive into his encrption program, or it could be via rigging the encryption program itself so that it will EMAIL you the key. Or it could be buying the key from him. In any event, this is by far the most likely way of cracking a secure cryptographic system -- the algorithms themselves are pretty much uncrackable, but key management is always a problem.
And of course the strength of the encryption has nothing to do with the strength of the cryptographic system. For example, one version of MS CHAP encrypted the password and sent it to the server. But -- it did not encrypt a salt that had been sent with the server along with the password. Thus all a bogon had to do was sniff the encrypted password, use it himself, and voila, as far as NT was concerned, the bogon was you.
-E
Send mail here if you want to reach me.
This is certainly one of my pet peeves... IDIOT firewall admins who turn off ICMP entirely, or worse, turn off everything but ICMP echo. ICMP exists for a reason. Sure, there are some parts that can be turned off without a problem, but you need to understand what the f*** you're doing -- which is at least 105% of the problem.
/* Echo Reply */ /* Echo Request */ /* Information Request */ /* Information Reply */ /* Address Mask Request */ /* Address Mask Reply */
As for that BS about routers using "ping"... no they don't -- or more accurately, none that are worth their weight in twinkies. There are much better ways to judge distance -- oh, say, like the TTL in any IP packet. (Note: bind does this already.) Additionally, if you knew anything at all about ICMP, you'd know there is no (zero, none!) transmittion assurance for ICMP traffic. Nothing is going to alert you an ICMP message never got to it's dest. nor will anything ever retransmit an ICMP message. (RFC) Rule #1: NEVER SEND AN ICMP MESSAGE ABOUT AN ICMP MESSAGE.
For the record, the parts that can be turned off without breaking the network stack are:
ICMP_ECHOREPLY 0
ICMP_ECHO 8
ICMP_INFO_REQUEST 15
ICMP_INFO_REPLY 16
ICMP_ADDRESS 17
ICMP_ADDRESSREPLY 18
Note: Turning off address mask info will break HP open spew.
Several years ago, I was about to buy a safe for my law office. As I lifted the safe off my shelf and on to the cart, I realized that it wouldn't be much use . . .
Someone, please! Moderate these posts up!
Because of people blindly blocking all ICMP, PMTUD (path maximum transmission unit discovery) is horribly broken for a large percentage of the internet.
The problem appears when you have a link between yourself and the destination that uses an MTU less than or not equal to (I can't remember which) the common 1500. What usually happens is small transfers work ok, but large transfers don't. So, you may be able to (for example) log in and get a directory listing from FTP sites, and even download small files, but trying to download large files just doesn't work properly. This has frustrated many people, as the problem is not easy to figure out. And once you do figure it out, the only way to fix things is to complain to the offending firewall operator, who will usually give a response like "Everything works fine for me. Must be a problem with your system.", or something similar.
"You're violating RFC xxxx" is just no match for "It works fine for me."
The only real solution is education.
So spread the word. Save the net.
I suggest buying a copy of Bruce Schneier's book "Applied Cryptography". He also has a web site (http://www.counterpane.com ) which has a lot of information that has trickled up through the ranks since the time that he wrote his book.
You are referring to what are called "side-channel attacks" when you talk about bribing the folks who do the encoding, and you are correct, side-channel attacks are the only effective attack against modern cryptographic techniques. You are referring to what is called a "man in the middle attack" when you set yourself up as the intended recipient of the encoded message, but there are known techniques for dealing with "man in the middle attacks" (read Bruce's book).
A cryptographic algorithm itself does not rely upon obscurity. The data is not obscure, it is effectively randomized. It does rely upon secrecy, in particular, upon the secrecy of the key. But secrecy is a different thing from obscurity -- obscurity is hiding a needle in a haystack in hopes that nobody will find it, while secrecy is carrying the needle around with you in your wallet. The difference is that someone might accidentally stumble over the needle in the haystack, but the needle in your wallet is never going to be stumbled upon by any intruder. Of course, if you leave it sitting on top of your dresser (like most people do with their "secret" keys), it's no longer safe from somebody stealing it! But that's a different issue altogether.
-E
Send mail here if you want to reach me.