Decrypting the Secret to Strong Security
farrellj writes "Cnet has an excellent article by Whitfield Diffie, who has probably has forgotten more about crypto than 99.9% of us will ever know, explains why secrecy does not equal security. The article also addresses the whole "open source vs proprietary software" security issue. A definite *must read* for anyone concerned about security...and that should be everyone!"
who has probably has forgotten more about crypto than 99.9% of us will ever know
What's the margin of error on that figure?
Whitfield Diffie, who has probably has forgotten more about crypto than 99.9% of us will ever know, explains why secrecy does not equal security.
For an excellent treatment of this important point, that secrecy != security, read Bruce Schneier's "Secrets and Lies: Digital Security in a Networked World".
It's the best book on the topic available.
Arr! The laws of physics be a harsh mistress!
I just double ROT-13 everything for maximum protection. It seems to work so far. -- Note this message has been encrypted with double ROT-13 any attempts to understand it will in violation of the DMCA and will be duly noted.
To me, that says that making sure the programs used for a company's network security or documents or whatever actually work and protect the network. Too bad it seems that a lot of companies lack the protection that is supposed to be a "natural function" of the company's network/data security personnel.
Ah am not a crook! (\(-__-)/)
Modest doubt is called the beacon of the wise. - William Shakespeare
... unless a woman enters the loop!
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
Whilst not quite in the random eye meaning of the article.
OSS does need proper audit and change tracking.
I've looked thorough quite a bit of OSS, and I've fixed a few bugs,
But apart from a patch there's no real way to track what code I thought needed atention, what was good and what was a mess.
Patches are good for tracking maturity/stability if used well, a section of the code that hasn't been patched for a while is either very stable or needs looking at.
thank God the internet isn't a human right.
One of his statements begs a question. Diffie says: "A secret that cannot be readily changed should be regarded as a vulnerability."
Yet asymmetric crypto (which I believe was publicised by Diffie and Helman (sp?) first) relies on one secret (the private key) being kept very very securely. Not only that, but if asymmetric crypto is to be any use, the secret should be kept for a fairly long time, as long as a signature needs to be valid. If you're going to use asymmetric crypto for legal purposes, to sign stuff, for instance, then the secret cannot be easily changed (unless there's some sort of central repository of keys that actually authenticates you properly when you ask to change your key, but even that is a bit dodgy).
Is it just me or does Diffie's statement, in a generalised form, kind of nullify the usefulness of asymmetric crypto? Or maybe I've missed the point...
Daniel
Carpe Diem
Whitfield Diffie, the co-inventor of public-key cryptography, is chief security officer and senior staff engineer at Sun Microsystems.
Could you please tell your hardware engineers to join the 21st century and provide full schematics and gerber files to all of your circuit boards? I'd like to examine the security of your hardware. After all, this is a good thing, right? The secrecy helps no one, and I'm only trying to help.
Thanks so much,
A Hardware Guy
Also check out the "cryptogram" newsletters that Bruce Schneier writes at counterpane.com. He devotes some of the newsletter to discussing current events/topics and the security involved therein. Very interesting stuff.
Diffie is definitely the guy to be talking about this. Considering a main form of private key-exchange is called Diffie-Hellman.
But, nontheless, it's silly that people don't know this inherently. A secure system is only as secure as its weakest point. If that point is compromised and cannot be easily fixed and/or repaired. It's useless.
Depending on the secrecy of the code or "Security through Obscurity" is useless. Anyone who tells you otherwise is a quack or is trying to sell you something and doesn't want to do all the work necessary to do the proper job.
If you want a secure system, you have to instantly assume that the system, code, and key will eventually be completely compromised, and then you can begin to think about. Now, if any of these were compromised, how can I fix the problem. The current solution is to reset the keys, and using modern mathematics (most of which was developed by Dif) You can do this securely.
Now, the only problem that remains with modern cryptography, is if the factoring problem is solved _and_ the elliptic curve problem is solved efficiently, then modern crypto becomes useless, and we are back to square one.
Albeit, Quantum Cryptography has some potential as it provides a mathematically verifiable form of perfect cryptography, since it is one time pads. It just currently cannot be done over long enough distances to be completely effective. When the technical/engineering details are solved for QC, then crypto is guaranteed secure. Assuming no one compromises your system directly (Human Error).
Dependence on Security through Obscurity is bad, incredibly bad, and I hope anyone programming security software out there will realize that, and begin to use proper cryptographic techniques.
** I am going to write a couple of journal articles soon reviewing the various techniques for those who are interested. **
~ kjrose
There are just too many ways to reverse engineer something these days
This is why everything should be open source! If everthing is put in plain view (and not protected by rediculous laws and coprights), then people that use crypto programs are more likely to ensure that they are truely secure
If everyone's eyes can see the program, then security can better be kept without an excessive need for an abundense of secrets
Just my $0.02 cents
HallmarkOrnaments.Com
Microsoft opens winows source to governments.... Link here
.ACMD setaloiv siht gnidaeR
I think we all know the answer to real security...Unplug your machine and never turn it on.
IMO the best browser game ever http://wittyrpg.com
How did Sun manage to make him work for them? Security-wise he alone is worth more than Microsoft's whole "Trustworthy Computing" campaign.
Signature deleted by lameness filter.
On the whole, though, apart those 2 arguments, the article seems quite hollow imo, just your usual arguments on both sides... (NOT trying to start a flame war here, just expressing my opinion, to which of course you can disagree ^_-)
Tsuyoikoto ha taisetsu da ne, dakedo namida mo hitsuyousa (Strength is an important thing, but tears too are necessary)
secrecy != security
True, I also tend to rely on complete lack of importance and relevance == Total insecurity.
I am so pathetic and worthless. Somebody love me?
I haven't seen anyone (save a few Slashdot trolls) seriously argue that binary-only software is inherently more secure, either in theory or in practice. So at first it sounds like Mr Diffie is setting up a straw man at the beginning of his article. But then you realize that the 'opponents' are not serious arguments but, on the whole, vague FUD wafting about that may be swallowed by less-technical people. So his article is an attempt to explain to the rest of the world what the security industry already knew.
-- Ed Avis ed@membled.com
"If you depend on a secret for your security, what do you do when the secret is discovered?"
Doh! That's obvious - Use the DCMA to sue their butts.
Perhaps its just me, but I'm reading between the lines that the issue really may not be Open Source vs. Commercial -- but who has the most to lose, in both intellectual property and in physical harm due to decryption by nere-do-wells.
I'm also seeing the same message over and over again, with this article, the book review previous to this article, and a few other articles that indicate that again, it comes down to human factors.
Again, the question becomes, how do we best secure the nut holding the keyboard?
--- have you healed your church website?
"It's simply unrealistic to depend on secrecy for security in computer software" -- what a succinct way to demolish the DMCA.
Nobody said a thing about trees before this post.
So yes, this post is redundant.
How many moderators are in charge of security?
If that makes you think, you are not a moderator.
THIS post is HILARIus and that is why i think it is funny.
here is obligitory repost of story!!
Watch out, Swami: Quickie now 3-1 on the people-competing-with-animals season, following last night's "Man vs. Beast" debacle. Correct: Elephant outracing 44 little people in jet-tug; sprinter placing between zebra and giraffe in 100m; Navy SEAL beating chimp in obstacle course. Missed: Kodiak bear ended up outgorging Japanese hot-dog-eating champ.
baseball fantasy leagues, there are controls in place to keep ambivalent managers of the going-nowhere teams with a couple great players from unfairly shoveling off those stars for next to nothing. Since Major League Baseball runs the Expos as well as the rules, however, they felt free to offload the best available pitcher, Bartolo Colon, to the White Sox in exchange for an essentially costless El Duque, while the Yankees contentedly reduced their logjam of starting pitchers and added a couple of relievers -- and, oh yeah, snickered at the Red Sox, who had to watch helplessly. Theo, we love ya, but ouch.
So, you think you cleaned all your personal files from that old computer you got rid of?
Two MIT graduate students suggest you think again.
Over two years, Simson Garfinkel and Abhi Shelat bought 158 used hard drives at secondhand computer stores and on eBay. Of the 129 drives that functioned, 69 still had recoverable files on them and 49 contained "significant personal information" -- medical correspondence, love letters, pornography and 5,000 credit card numbers. One even had a year's worth of transactions with account numbers from a cash machine in Illinois.
About 150,000 hard drives were "retired" last year, according to the research firm Gartner Dataquest. Many end up in the trash, but many also find their way back onto the market.
Over the years, stories have surfaced about personal information turning up on used hard drives, raising concerns about privacy and the danger of identity theft.
Last spring, Pennsylvania sold used computers that contained information about state employees. In 1997, a Nevada woman bought a used computer and discovered it contained prescription records on 2,000 customers of an Arizona pharmacy.
Garfinkel and Shelat, who reported their findings in an article to be published Friday in the journal IEEE Security & Privacy, said they believe they are the first to take a more comprehensive -- though not exactly scientific -- look at the problem.
On common operating systems such as Microsoft's Windows, simply deleting a file, or even following that up by emptying the "trash" folder, does not necessarily make the information irretrievable. Those commands generally delete a file's name from the directory. But the information itself can live on until it is overwritten by new files.
Even reformatting a drive, or preparing the hard drive all over again to store files, may not do it. Fifty-one of the 129 working drives in the MIT study had been reformatted, and 19 of them still contained recoverable data.
The hard-to-erase quality of hard drives is seen as a good thing by some. Many users like believing that, in a pinch, an expert could recover their deleted files. Law enforcement officers can examine a computer and lift incriminating e-mails or porno images from the hard drive.
The only sure way to erase a hard drive is to "squeeze" it: writing over the old information with new data -- all zeros, for instance -- at least once, but preferably several times. A one-line command will do that for Unix users, and for others, inexpensive software from companies such as AccessData works well.
But few people go to the trouble. Many ordinary computer users toss their old drives into the closet, or take a sledgehammer to it.
As it turned out, most of the hard drives acquired by the MIT students came from businesses that apparently had a misplaced confidence in their ability to "sanitize" old drives.
Tom Aleman, who heads the analytic and forensic technology group at the accounting firm Deloitte & Touche, often encounters companies that get burned by failing to fully sanitize, say, the laptop of an employee who leaves the company for a job with a competitor.
"People will think they have deleted the file, they can't find the file themselves and that the file is gone when, in fact, forensically you may be able to retrieve it," he said.
Garfinkel has learned his lesson. As an undergrad at MIT in the 1980s, he failed to sanitize his own hard drive before returning a computer to his father. His father was able to read his personal journal.
THIS post is HILARIus and that is why i think it is funny.
here is obligitory repost of story!!
Watch out, Swami: Quickie now 3-1 on the people-competing-with-animals season, following last night's "Man vs. Beast" debacle. Correct: Elephant outracing 44 little people in jet-tug; sprinter placing between zebra and giraffe in 100m; Navy SEAL beating chimp in obstacle course. Missed: Kodiak bear ended up outgorging Japanese hot-dog-eating champ.
baseball fantasy leagues, there are controls in place to keep ambivalent managers of the going-nowhere teams with a couple great players from unfairly shoveling off those stars for next to nothing. Since Major League Baseball runs the Expos as well as the rules, however, they felt free to offload the best available pitcher, Bartolo Colon, to the White Sox in exchange for an essentially costless El Duque, while the Yankees contentedly reduced their logjam of starting pitchers and added a couple of relievers -- and, oh yeah, snickered at the Red Sox, who had to watch helplessly. Theo, we love ya, but ouch.
So, you think you cleaned all your personal files from that old computer you got rid of?
Two MIT graduate students suggest you think again.
Over two years, Simson Garfinkel and Abhi Shelat bought 158 used hard drives at secondhand computer stores and on eBay. Of the 129 drives that functioned, 69 still had recoverable files on them and 49 contained "significant personal information" -- medical correspondence, love letters, pornography and 5,000 credit card numbers. One even had a year's worth of transactions with account numbers from a cash machine in Illinois.
About 150,000 hard drives were "retired" last year, according to the research firm Gartner Dataquest. Many end up in the trash, but many also find their way back onto the market.
Over the years, stories have surfaced about personal information turning up on used hard drives, raising concerns about privacy and the danger of identity theft.
Last spring, Pennsylvania sold used computers that contained information about state employees. In 1997, a Nevada woman bought a used computer and discovered it contained prescription records on 2,000 customers of an Arizona pharmacy.
Garfinkel and Shelat, who reported their findings in an article to be published Friday in the journal IEEE Security & Privacy, said they believe they are the first to take a more comprehensive -- though not exactly scientific -- look at the problem.
On common operating systems such as Microsoft's Windows, simply deleting a file, or even following that up by emptying the "trash" folder, does not necessarily make the information irretrievable. Those commands generally delete a file's name from the directory. But the information itself can live on until it is overwritten by new files.
Even reformatting a drive, or preparing the hard drive all over again to store files, may not do it. Fifty-one of the 129 working drives in the MIT study had been reformatted, and 19 of them still contained recoverable data.
The hard-to-erase quality of hard drives is seen as a good thing by some. Many users like believing that, in a pinch, an expert could recover their deleted files. Law enforcement officers can examine a computer and lift incriminating e-mails or porno images from the hard drive.
The only sure way to erase a hard drive is to "squeeze" it: writing over the old information with new data -- all zeros, for instance -- at least once, but preferably several times. A one-line command will do that for Unix users, and for others, inexpensive software from companies such as AccessData works well.
But few people go to the trouble. Many ordinary computer users toss their old drives into the closet, or take a sledgehammer to it.
As it turned out, most of the hard drives acquired by the MIT students came from businesses that apparently had a misplaced confidence in their ability to "sanitize" old drives.
Tom Aleman, who heads the analytic and forensic technology group at the accounting firm Deloitte & Touche, often encounters companies that get burned by failing to fully sanitize, say, the laptop of an employee who leaves the company for a job with a competitor.
"People will think they have deleted the file, they can't find the file themselves and that the file is gone when, in fact, forensically you may be able to retrieve it," he said.
Garfinkel has learned his lesson. As an undergrad at MIT in the 1980s, he failed to sanitize his own hard drive before returning a computer to his father. His father was able to read his personal journal.
when you include ideotic humans security goes to the birds
My IP is 127.0.0.1. Do your worst.
slashdot!=valid HTML
The code included a function specifically for a_times_b_mod_c using arbitrarily large numbers, and we used this function in the interest of speed. Unfortunately, there was a bug which caused the function to return a 0 result a little more often than expected (with C being "almost certainly" prime, it should almost never return a 0).
Fortunately, though, a 0 caused an error, rather than an insecure connection. When we got rid of the special function and instead used the overloaded * and % operators, everything worked fine.
I know there must have been more than a few eyeballs looking at the code in that function -- including mine -- but a potentially devastating bug snuck through. Heck, I didn't have a clue how that code was supposed to work. It was too mathematically complex for me.
The moral of the story? I suppose it's just this: the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms.
Haha ... cute :)
For those of you who don't know, he's the co-inventor of public-key cryptography. Bow to him, because we're not worthy!
Whitfield Diffie, who has probably has forgotten more about crypto than 99.9% of us will ever know, explains why secrecy does not equal security.
And he would tell us all about it if he had a mouth
Mouse powered Chips, Open source Processors and Lego
Wrong. S&L is the best book to give to your boss to get hir to understand why you want to devote a bit of time to securing your new product instead of releasing it as soon as it's semi-functional. S&L is not a very technical book (not like Applied at all), and parts are chapter-long advertisements for Bruce's new-at-the-time-of-publishing business, but but it can be appreciated even by marketdroids and pointyhairs.
Returned Peace Corps IT Volunteer
"This isn't a study in computer science, its a study in human behavior"
If microsoft opened up their all their software tonight. Tomorrow morning every windows server would be down, every internet-connected desktop would be down, Infact anything that could be down would be down. Open source software such as linux is probably on a higher level than closed source, so the majority of bugs that could be found in linux already have. For example, if you open fire randomly at a crowd with a machine gun, you'll hit more people in the first few seconds than in the next minute, because after you've taken out the bulk, what your left with is afew scattered people that are harder to pick off - anyone who plays fps's will know what i mean.
This comment does not represent the views or opinions of the user.
...an open source programmer who uses concepts that originate from outside of the whole world of programming/hacking/fragging.
A secret that cannot be readily changed should be regarded as a vulnerability.
Support Israeli punk bands. Man Alive.
I forget who said this, but there's a real paradox with security that the more you THINK you have, the more risks you will take, and therefore the less safe you are. When you know you are vulnerable, it heightens the senses, focuses your awareness. You're sharper, because you have to be.
I'm not saying throw the security away, but think about this: trusting on a secret can make you complacent just as Diffie writes. Knowing your code is Open Source and everyone can look at it should help you focus on the real problem, which is that security is a moving target and needs constant evaluation.
I agree with WD's theme, but his defense of Open Source has a weak/irrelevant point.
I think auto-manufacturer responsibility is anchored in legal liability. If the wheels come off, the builder is sued, no matter whether the engineering diagrams are freely available to the car's owner.
Yes, but it doesn't mean someone is. He's arguing in favour of a (legally liable) vendor.
As noted by other posters, the basic arguments have been written in more detail by people like Bruce Schneier -- see his Cryptogram newsletters for some well-thought-out writing.
A nice little article, suitable for sharing with less-technical coworkers.
je ne suis pas un fou
.."Security through obscurity is no security"..
Can you explain what a password is if it isn't security through obscurity?
Consider a website that has on the front page a login box with the prompt "Admin Password:".
How is that any more secure than an "security through obscurity" approach, whereby the developer has made himself the following admin URL:
http://www.example.com/3458976394534/admin.html
Both the password, and the hidden URL are equally hard to guess. Yet people go on about how security through obscurity is no security.
Is anybody with me on this?
"If you depend on a secret for your security, what do you do when the secret is discovered? If it is easy to change, like a cryptographic key, you do so. If it's hard to change, like a cryptographic system or an operating system, you're stuck. You will be vulnerable until you invest the time and money to design another system."
The author has rightly pinpointed the pivotal dilemma of quite a many software designers. The problem is more about defining boundaries for modules handling security of the system. Do you integrate it strongly with the rest of the system? That creates a problem if a vulnerability is discovered and you have to invest more time and finances into taking care of all those 'integration points'. Do you design like a true pluggable module and let the system interact with it using few interfaces? That makes your whole system more transparent (some closed-source companies may whine here) and there may be possibilities of someone spoofing this external interface altogether. A balance is definitley required, but surprisingly most software designs seem to miss this point completely.
OSS can be viewed by many eyes.
... but security in the OSS world has yet to be proven.
But is it?
Can you be sure that each and every code change is reviewed by competent individuals trained and experienced in security and with a comprehensive knowledge of the architectural issues with the work product? By each and every we include device drivers from every source under the sun that are in the kernel and thus have the ability to do good things or ill.
Who maintains the security model, the design documents, the overall architecture? Who argues that this code, while it speeds things up wonderfully, violates architectural principles that are important to the security of the entire system? And who can make the decision stick...that security is more important than functionality or speed.
Yes OSS could be more secure than most proprietary products by virtue of the quantity of eyes.
But perhaps it is possible to make a product even more secure by following great developmental practices, ones that are only enforceable in a proprietary world. And submitting it to peer review by acknowledged experts.
Compare the assurance requirements contained within the Common Criteria to the practices followed in most OSS product development and maintenance. OSS has some real problems.
Not that it isn't wonderful
For someone who is supposed to be an utmost authority in crypto...his article was very lacking in anything that remotely addressed the issue of the question at the heading 'Is open-source software better for security than proprietary software?'
It addressed secrecy as a form of security...proprietary software is NOT secrect software.
I just feel that someone with his credentials should have been able to come up with some arguement or form of support. All in all I wouldn't recommend the article to be read at all, for it lacks any insight on the topic it was supposed to address.
"Just Smile and Nod." --Huck
Passwords can be seen as a secret used for security. The author also mentions cryptographic keys in the same context. He justifies them by saying that because they can be easily changed, they aren't a great detriment to security. I'm not sure I agree. In the past, the most common way to gain unauthorized access to a machine was through weak passwords. And even if you have a strong password, it may be difficult to know if it becomes compromised.
I've always wished for a system like RSA'a SecurID cards. They give you a password that changes every 60 seconds, and you carry around a token that shows the latest password for you. Unfortunately, such technology is priced out of the range of individuals like me.
For every post, there is an equal and opposite re-post.
Passwords can be changed, and can be changed quickly. If you discover a password has been compromised, locking down the system is a password change away.
If you want to be really secure, change your password daily. Or hourly. Or after each transaction.
But once your obfuscated URL is discovered - and discovering it is trivial - then the secret is out, and what little protection it did provide is lost until you can change the obfuscation.
For the best example, see the CSS system used on DVD players. That security system hinged on keeping something secret. Once it was discovered, there was no way to put the cat back in the bag without changing the key on everything that needed to be able to read DVDs - and obviously, the MPAA couldn't do that without rendering all the DVD players out there nonfunctional.
Secrets, as part of a security system, are BAD. They only become acceptable when they can be quickly changed once compromised. If they cannot be changed quickly, they render you more vulnerable than if they were out in the open to begin with.
DG
Want to learn about race cars? Read my Book
The secret to strong security: less reliance on secrets
The "funny"/scary thing is that the majority of credit card usage/processing falls under this statement.
Think about it. People shred there cc receipts, they demand secure links to ecommerce sites, they shroud their credit cards and SSN's from prying eyes. Yet, you hand your CC to Joe Sixpack at the gas station or the waitress at the restaurant. I remember back in the day when I worked at a service station, I relized back then that I could simply collect peoples CC#'s and use them surreptitiously. Yes there are more safeguards now, but it still is simple to do. Anyone who thinks that their CC is truely secure is fooling themselves.
So what you do is to make reasonable efforts to keep things secure, but ALWAYS check your statements, and be ready to act if something happens.
I have to disagree. Secrets and Lies is a great book because it is not technical. It presents clearly the problems and challenges associated with securing a system, and then discusses means to solve the problems and overcome the challenges. It makes you realize that security must be an integral part of a system, not a bolted-on afterthought.
In discussing these things in a non-technical manner, Schneier gets you (as a developer) to stop thinking about which trendy algorithm or PKI you're going to tack on to your product to call it secure, and start thinking about the security of the system itself. So you use cryptography; so what? What's the point in encrypting your data if you don't also ensure its authenticity and origin? You're using PKI to secure communications; so what? Are you also ensuring the security and integrity of the keys' local storage? Security is a process, not a product, and the biggest problem with purely technical books on cryptography or security (they're not the same thing) is that they give the impression that you can sprinkle their code samples throughout your project and have it be magically secure.
It's a bit like me reading a book on security and declaring myself an expert because I read a book on security. Knowledge != understanding.
Arr! The laws of physics be a harsh mistress!
If your secret (private key) becomes known, sure you now have the cost of creating a new key, revoking your old key, and making sure the trusted depository has both. Also, this does not eliminate some risks in others having trusted documents signed with your old key by your nemesis during the interim (or by those who fail to verify the key has not been revoked). But this cost is nowhere near the cost of designing a replacement algorithm were it the case we were using one which depended on secrecy to avoid being compromized. Not only would there be that cost of redesigning, but also the cost of having no reliable system in the interim. Instead, just one entity (you, if your secret key gets out) incurs the costs. This is also why keys should come with a set expiration date, so that those who trust them won't extend their trust too far.
It's 2003. Have you changed all your passwords, yet? Have you created new SSH keys and removed all trust of the old ones?
now we need to go OSS in diesel cars
ALRIGHT! That was post #100 for this topic, meaning I am the ultimate first poster, the first poster firster, the only poster first, and i am hell of a lot sexy =er than you.
I wrote up my view of the article and posted it earlier. I think that (for obvious reasons) he tends to view things from a cryptography perspective and tends to miss what really happens "on the ground", but hopefully his voice will be influential in such matters among his colleagues.
"You can never have too many elephants on your team."
If OSS is so great, why does the bloke work at Sun? :-)
It's the best book on the topic available.
Actually, I beg to differ. Security Engineering by Dr Ross Anderson is IMHO a far more rigorous treatment of this subject. Details are here. It's even just as easy to read as Schneiers book...Of course, Bruce is a far better at self marketting.
I am looking forward to getting Schneiers new Practical Cryptography book though (here).
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
Okay, I'll bite.
I shred all personal documents (and junk mail and crap) to make it more difficult if someone wanted my personal information. It isn't foolproof, but it doe smake me a harder target, which is all I want.
(Two men are in the woods, they run into an enraged bear, one of them takes off running, the other says "what are you doing, you can't outrun the bear". The first replies "The bear? I only have to outrun you")
Secondly anyone can copy my CC number, you just need to look at the card, perhaps take a picture. I rely on the fraud protection to protect me.
It isn't perfect, or even secure, but I think if I put enough barriers up, it might just be troublesome enough for people to avoid.
To which I would add: I regularly check my brake fluids (and other stuff). However, most people I have seen who are not pilots don't even do a walk-around of their vehicles, they just jump in and go. Certainly I am not proposing each user become a "mechanic", but some basic training would go a long way.
This little penguin doesn't forget favors
I have a couple of rottweilers and make no secret of it. Wanna try some social engineering on them?
Poison Steak.
PLEASE someobdy jsut ban wait let me restart please somebody just ban this whole damn city from slashdot!
Wow, I didn't know Jeff K. posted on slashdot.
Dacels Jewelers can't be trusted.
Every seen how much steak it takes to bribe a Rottweiler? It's gonna cost you an arm and a leg ;)
That's OK as long as it isn't my arm and leg!
I have more confidence in SSL-enabled web sites than I do using my card at places like restaurants where exactly that kind of compromise can happen. I have a fair amount of confidence that the first time I got a monster fraudulent charge on my card it was compromised at a restaurant. The card was a VISA check card which had not ever been used on the Internet to order anything. Since it snarfed money directly from my checking account, I was in deep shit. Lousy bumfucker got a plane ticket to Miami on my dime. At least it was easily reversed...too bad about those NSF charges it generated...
Obscurity can help a systems security but it cannot be relied upon. Diffie knows this. This is why NSA does not publish the crypto algorithms that they use. They certainly don't rely on this obscurity however.
Running SSH on a non-standard port is obscurity. It does not replace keeping up to date on patches. It can however help keep your system from being compromized if a fast moving SSH worm were to take off. It will give a bit of time to get the patch in place.
Any piece of software will benefit from a dedicated security audit whether it is closed or open source. If we want software to be more secure we should be demanding that publishers audit the code before foisting it out on the world whether open or closed source. If all closed source vendors actually did this and fixed the problems there is no doubt in my mind that closed source software would be more secure. I am not holding my breath however.
-weld
i'm glad to see he somewhat, as i read it, defends open source. as a 19 year old just getting started with web development one of my worries has been convincing potential clients that php is not less secure than asp. sometimes it's hard to explain the benefits to those who don't understand. hopefully this article will be a good tool for me to use.
all i see are 1's and 0's
Hey, he must have come up with the premise for 'Sneakers' also -- "too many secrets"!!
considering the guy co-wrote one of the most important cryptographic algorithms used in most key exchanges.
come on fhqwhgads
try a couple of Pit Bull's on em.
I have a friend who used to work at Counterpane, and let me tell you this all sounds good on paper,
but in real life security is much harder to achieve. The crypto math is rarely the weak point.
My friend related stories about times he discovered a customer that had been hacked months after
the original attack. Since Counterpane didn't alert them right away (like the contract called for),
they just didn't tell them unless they saw further intrusions. Not only that, but there were numerous cases
where one companies security alert was sent to a different company.
The bottom line is that people will almost always be less secure than the crypto math.
"These weiners will give me the quick energy I need to escape!" - H. Simpson
"I'm not impatient. I just hate waiting." - My Dad
Schneier's Secrets & Lies is indeed excellent.
For another excellent but more technical book on security I would recommend Building Secure Software.
Building Secure Software has a foreward by Schneier in which he writes: "Read it; learn from it. And then put its lessons into practise."
Chapter 4 in the book is "On Open Source and Closed Source".
A most own book if you are interested in software security.
If you qualify the statement as shared secret then it's pretty much correct. A private key (in a public/private pair) is never held by anyone other than the owner, nor is it necessary to transmit it in any way. And he can keep better track of it than anyone else can (or at least, he should).
Unfortunately this sounds like an argument AGAINST open source in the enterprise. How much money should an enterprise budget to audit each open source program, including patches, etc? Who would approve that budget when closed source programs come "pre-audited" in the eyes of the PHB?
There are Key Distribution System approaches using symmetric keys, such as Kerberos, that we'll have to remember how to do if this happens. They're not as nice as public-key, and I'm not aware of any digital signature systems using them (which is a big lose), but they can still provide privacy.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Thanks for the pointer. I'll be sure to read Dr. Anderson's book next.
I'm looking forward to Schneier's next one, as well.
Arr! The laws of physics be a harsh mistress!
Why does reading this article with that in mind give me the willies?
Hmmm...that works for the patch repository, but I'm not sure it's perfect for the legal situation. Let's say Alice wants to get out of a digital contract with Bob, she merely has to state that her key was compromised _before_ the notary's time stamp. But I'll bet that someone has already come up with a better contract signing algorithm.
First, I said "for software you sell", which means, it is not the individual developers who are liable, liability follows the money. Distro-makers would be liable for the product they sell. As well, of course, as vendors of proprietary software.
Liability would mean that the distro-makers actually get a product, they sell a warranty, and that warranty would mean that they would have to more carefully audit the code of the software they sell. Thus, they could ask higher prizes, then they could afford to employ more hackers to audit the code. Net result, we all gain, because the code that makes it into commercial distros gets more professional attention.
Also, since we all know that Free Software is better from the outset than proprietary counterparts, we would get a head start, and M$ would spiral down as they get hit with big law-suits... ;-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Actually, The January '03 CryptoGram (mailed out yesterday) has an article discussing AES, RMAC and 3DES discussing how "secure" it is, and in reality, why it is not secure. Check it here.
Linux: The world's best text-adventure game.
I second that. Security Engineering is the best and most entertaining security book that I have ever read.
Aside from covering up weak design, and providing higher performance back when that was still a limitation of general-purpose hardware, there actually are good reasons for hardware crypto. The primary one is key protection - software systems make it too easy to leak keys, and whether you're using persistent keys of some sort for identity and authentication or only using Diffie-Hellman key exchange to create transient keys, you still need to protect them during a session.
One way to look at binary-only software is that it's really just bad documentation; source code is much better documentation. It's unable to keep secret keys secret, and as demonstrated a couple of years ago, there's no guarantee that some 15-year-old kid won't figure out how to use your code as well as revealing how lame it is :-)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Is that the Chief of Staff of Sun Microsystems has hippie-hair and an unkempt beard.
hi, I like pancakes -.-- -.-- --..
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
hey, where's my karma bonus?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The more serious problem is applications from major software vendors that include passwords or other security features that aren't secure, and are closed-source not to protect the crypto, but just because they're proprietary applications. A couple of obvious examples are A Popular Word Processor from a Large Company in the Northwest and Several ZIP archivers that have passwords and Microsoft's initial PPTP products which totally botched their use of RC4 and had several other serious bugs.
A somewhat different example is RSA's trade-secret-limited sale of the RC4 algorithm and implementations of it. That wasn't kept secret to protect it against crackers, it was kept secret so they could charge money for toolkits instead of people implementing the algorithm themselves, possibly more successfully than patent licensing on RSa public-key had been, and the reason to believe it was secure was that it was written by Ron Rivest and checked by his coworkers, who are one of the few groups with enough credibility to get away with such an otherwise-dodgy approach. (The NSA and KGB can also, but besides having a repuration, they've also got a captive audience...)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
For all of you who read Steven Levy's Hackers, you should remember who he is. Levy devotes chapters and chapters to him.
-----
Score 3? For what? Being wrong, at length? - smirkleton
The US government has a lot of secrets. Whole agencies even existence have been secrets for decades (like the NSA); how many do we not know about today? And there's the secret black budget written by congress.
Imagine a middleman attack on this system.
Your forge up some fancy documents, then go recruit some people to your secret organization. Ostensibly, you are a secret arm of the TLA, a super-secret black-op, so they have to be discrete. You then have those employees recruit more people for you.
If you do it right, you will soon have a large organization made up of people who believe they are working for a secret national security agency willing to do just about anything because they are patriots. This will take money, but given that you are a black-op, nobody can track your finances, which most likely come from clever schemes where your 'agents' unwittingly secure loot for you to buy more agents. All in the name of national security, so you never have to explain yourself. If one of your recruits gets caught doing the bad thing, they will have been trained to keep mum, and since you operate like a real black-op, you won't be easily rooted out. If you trained your first recruits well, most people in your 'agency' won't even know you exist.
Anyway, if you use your imagination a little bit you might be able to scare yourself.
Could this work? Is anyone so stupid to fall for it? Sadly, yes. There are a lot of gullible people in the world. A close aquaintance of mine believes to this day that the FAA is really a secret organization with assassins, aircraft navigation VORTACS are black op bases that somehow shoot down soviet nuclear missles. She actually thinks she was a secret agent doing missions for the FAA. She won't tell me what she did, but implications are that the people she 'worked' did some really nasty deeds.
I hasten to point out that the article was a criticism of RMAC. Just in case someone skimmed the parent post and promptly had a breakdown, thinking that 3DES was no longer The Mack.
-----
PGP Key ID 0xCB8FF658
> ... "Security through Obscurity" is useless.
I agree that Security Through Obscurity is far, far from adequate, but it is not useless. It can be useful as part of a security scheme that depends on other, stronger defenses.
The less the opponents know about you, the tougher it is for them to recognize your vulnerabilities.
And there are _always_ vulnerabilities.
...that cryptographers and mathematicians still have to remind people the most basic things about security. It's especially sad that they have to remind those things to programmers.
Contrary to the popular belief, there indeed is no God.
I connected up to your IP, but all I found was this folder full of fake Olsen Twins porn... :(
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
I don't know why people try to show off by saying one or two facts on basic crypto stuff like simple PK algorithm like RSA. Are you trying to show off that you are smart? More like triyng to show off your ineptness since half of the posts written by these show offs don't know what the hell they are talking about.
Ransom Love?
Why not fork?
http://www.example.com/3458976394534/admin.html
If you are sure you don't have any web proxies in your way, and your browser doesn't show or store the URL in any way (history, bookmarks, cache, etc.), then it is probably as secure as a clear-text HTTP password --- it only leaks to packet sniffers.
The problem is that it is hard to make sure that your software and web proxies don't do the wrong thing, because all software know that HTTP password should be secret and not be logged or stored in cleartext, but noone knows a URL should also be secret!
okay, the guy is a genius, but this article doesn't say anything new nor does it prove anything.
we all know security through obfuscation (or secret) is always going to have a hole.
guess what, passwords, password phrases, keys, certs, they're all secrets too. i don't know of any security protocol/technology that doesn't involve some sort of secret be it your fingerprint, a password, a changing code on a keycard, etc. all we can do is make the secrets as difficult as possible to discover.
Offtopic rant:
why must even diffe resolve to the always inapplicable but ever present automobile-software analogy?
what everyone seems to forget is that someone has to build the cars, it takes a lot of money to build them, and they are also easy to sell because you can't easily build one yourself, thus you have to buy one.
comparing automobiles to software code is therefore ludicrous. just because you have all the plans for a car doesn't mean you can build one. however having all the code to a piece of software certainly does mean so.
End of Offtopic Rant
in this age of communication i'm just not getting through
FAWKKKKK