Book Review: Security Without Obscurity 51
benrothke (2577567) writes Having worked at the same consulting firm and also on a project with author J.J. Stapleton (full disclosure); I knew he was a really smart guy. In Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity, Stapleton shows how broad his security knowledge is to the world. When it comes to the world of encryption and cryptography, Stapleton has had his hand in a lot of different cryptographic pies. He has been part of cryptographic accreditation committees for many different standard bodies across the globe. Keep reading for the rest of Ben's review.
The premise of the author and the need for the book is that the traditional information security CIA triad (confidentiality, integrity, availability) has led to the situation where authentication has to a large part gotten short shrift. This is a significant issue since much of information security is built around the need for strong and effective authentication. Without effective authentication, networks and data are at direct risk for compromise. | Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity | |
| author | J.J. Stapleton |
| pages | 355 |
| publisher | Auerbach Publications |
| rating | 8/10 |
| reviewer | Ben Rothke |
| ISBN | 978-1466592148 |
| summary | Great guide to enterprise authentication from an expert |
The topic itself is not exactly compelling (that is, unless you like to read standards such as ANSI X9.42-2003: Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, ISO/IEC 9798-1:2010: Information technology — Security techniques — Entity authentication,etc.), so the book is more of a detailed technical reference. Those looking for a highly technical overview, interoperability guidance, and overall reference will find the book most rewarding.
For those who don't have a general background on the topic; it may be a book too deep and technical for those looking for something more in line of a CISSP preparation guide.
For those that want to know the deep underpinnings of how encryption algorithms work; they can simply read the RFC's and standards themselves. What the book brings to the table are details about how to effectively implement the standards and algorithms in the enterprise; be it in applications, policies; or the specific procedures to meet compliance and standards requirements. And that is where Stapleton's many decades of experience provide significant and inestimable value.
There are many reasons why authentication systems fail and many times it is due to interoperability issues. Stapleton details how to ensure to minimize those faults in order to achieve seamless authentication across multiple technologies and operating systems.
The 7 chapters cover a dense amount of information around the 3 core topics. The book is for the reader with a solid technical background. While it may be listed as an exploratory text, it is not like a For Dummies title.
As per its title, it covers confidentiality, authentication and integrity; in addition to other fundamental topics of non-repudiation, privacy and key management.
One of the ways Stapleton brings his broad experience to the book is in the many areas where he compares different types of cryptosystems, technologies and algorithms. This enables the reader to understand what the appropriate type of authentication is most beneficial for the specific requirement.
For example, in chapter 7, the book provides a really good comparison and summary of different cryptographic modules, including how they are linked to various standards from NIST, NSA, ANSI and ISO. It does the same for a comparison of cryptographic key strengths against various algorithms.
An interesting observation the book makes when discussing the DES encryption algorithm, is that all of the talk of the NSA placing backdoors in it are essentially false. To date, no known flaws have been found against DES, and that after being around for over 30 years, the only attack against DES is an exhaustive key attack. This type of attack is where an adversary has to try each of the possible 72 quadrillion key (256permutations – as the key is 56 bits long) until the right key is discovered.
That means that the backdoor rumors of the NSA shortening the length of the substitution ciphers (AKA s-boxes), was not to weaken it necessarily. Rather it was meant to block DES against specific types of cryptanalytic attacks.
While the book is tactical; the author does bring in one bit of trivia when he writes that the ISO, often known as the International Organization for Standardization, does not in truth realty stand for that. He notes that the organizations clearly states on its web page that because International Organization for Standardization would have different acronyms in different languages (IOS in English, OIN in French for Organization internationale de normalization, etc.); its founders decided to give it the short form ISO. ISO is derived from the Greek isos, meaning equal. Whatever the country, whatever the language, the short form of the name is always ISO.
While that is indeed ultimately a trivial issue, I have seen certification exams where they ask what that acronym stands for. Perhaps a lot of CISSP's need to have their credentials revoked.
While Stapleton modifies the CIA triad, the book is not one of a security curmudgeon, rather of a security doyen. For anyone looking for an authoritative text on how to fully implement cross-platform security and authentication across the enterprise, this is a valuable reference to get that job done.
Reviewed by Ben Rothke
You can purchase Security without Obscurity: A Guide to Confidentiality, Authentication and Integrity from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books are available from our review library please let us know.
First Rule of secure coding. (Score:5, Insightful)
The first rule is the following.
Code it so you yourself couldn't get in without proper authorization.
Now this doesn't mean your program in invulnerable or someone with more skill could get in. But it gets you thinking in the right mindset.
Back in the good old days, it was common to have a back door. So you could get in if something went wrong. This wasn't a bad idea at the time, because most people wouldn't try going thew the back door that they don't know about, because they didn't know about it... However today many of these hacks are automated. And hit your system not because you have been pegged as worthy of getting broken into, but because the system found an opening and took advantage of it.
So if you can get in without your authorization then you need to work harder to secure your system.
Re: (Score:2, Insightful)
The problem is that we, as coders and engineers want to do the right thing from the ground up.
However, a lot of companies don't want to pony up for doing it "right". They want their guys in the offshore bargain basement dev house to make it "secure", while paying the bottom rupee amount needed to ship the product. Since it is viewed by a lot of PHBs that security has no ROI, why pay more than lip service?
As for back doors, it isn't that hard to make one that is still secure. You have two sections. One p
Re: (Score:1)
Re: (Score:2)
"Do you know any large system where this works? The big gotcha is that of all the programs you run, you can only code a tiny % of them. And you canâ(TM)t audit everything else."
if you can't audit 7mb of code you're retarded. who has a 7 mb of code to audit it? try openbsd http://www.openbsd.org/ftp.html [openbsd.org]
even for the full iso is only 230MB. plop it on open hardware and you can audit the hardware and the software. someday get a 3d printer and an x-ray camera and you can audit the hardware to see if it fo
Re: (Score:1)
Re: (Score:1)
So the first rule: don't do crypto
Re: (Score:2)
Crypto is only a small part of security. It in many ways is over exaggerated in its effectiveness.
It is true that when your packet leaves your network you have no control on where the data goes threw, so someone in the middle can read and port scan your data, that is why Crypto is useful and should be used. But...
Most networks do not use Hubs but smarter switches and routers, where they don't log all the traffic that goes threw them so chances are that random packet that is going from professional network
Re: (Score:1)
Re: (Score:2)
This wasn't a bad idea at the time, because most people wouldn't try going thew the back door that they don't know about, ...
It was still a bad idea then. It's just that there were a lot fewer script kiddies and bots looking for back doors and exploits back then than there are now.
OpenSSL disagrees (Score:3)
Maybe obscurity doesn't mater after all
Re: (Score:3)
Security through Obscurity works, just as camoflage works for soldiers. And relying just on Security through Obscurity works just as well as camoflaging your soldiers and then sending them out without weapons, ammo, food, water or training into a hostile environment.
Meta-review (Score:5, Insightful)
These Slashdot book reviews have become useless. In general, if you have a book review, go put it on Amazon.com.
In this case, the review is confusing and spends too much time on anecdotes, trivia, and debunking misconceptions. It's also totally in conflict with itself:
The topic itself is not exactly compelling..., so the book is more of a detailed technical reference. Those looking for a highly technical overview, interoperability guidance, and overall reference will find the book most rewarding.
So is the book a detailed technical reference, a highly technical overview, or an overall reference? I'm totally confused.
A good review might start with an expanded table of contents, explaining the topics in the book, what level of expertise is required, and which ones were most poignant. If the reviewer has read other books on the subject, perhaps compare them.
(Next: someone will post a review of this comment, producing a meta-review-review)
Re: (Score:2)
One of the ways Stapleton brings his broad experience to the book is in the many areas where he compares different types of cryptosystems, technologies and algorithms. This enables the reader to understand what the appropriate type of authentication is most beneficial for the specific requirement.
Could easily be written as:
Stapleton compares different types of cryptosystems, technologies and algorithms.
Leaving plenty of space to list more concrete information from the book, like the Parent suggested: a table of contents.
Re: (Score:1)
The good thing about putting the book review on Slashdot is to potentially give a "heads up" to folks about a book they may not have been aware of. In my case I am now aware of this book and it is a topic I am interested in.
I didn't even read the review. I look at the rating and if it is reasonable (usually 7/10 or higher), I'll head over to Amazon to read the reviews there.
Re: (Score:2)
Thanks for the helpful comments.
Re: (Score:2)
Either Ben or Stapleton is missing something (Score:4, Insightful)
There was a time when the NSA had integrity....
Re: (Score:2, Insightful)
There was a time when the NSA had integrity....
Good joke.
In 1975-76, Diffie and Martin Hellman criticized the NBS proposed Data Encryption Standard, largely because its 56-bit key length was too short to prevent Brute-force attack. An audio recording survives of their review of DES at Stanford in 1976 with Dennis Branstad of NBS and representatives of the National Security Agency.[5] Their concern was well-founded: subsequent history has shown not only that NSA actively intervened with IBM and NBS to shorten the key size, but also that the short key size enabled exactly the kind of massively parallel key crackers that Hellman and Diffie sketched out. When these were ultimately built outside the classified world, they made it clear that DES was insecure and obsolete. In 2012, a $10,000 commercially available machine can recover a DES key in days.
http://en.wikipedia.org/wiki/W... [wikipedia.org]
Yeah, real integrity there...
Re: (Score:2)
I think everyone outside of the NSA wanted a longer key length than 56-bits.
But the main comment from the book was that the DEA withstood the test of time, aside from hardware catching up to it and making exhaustive key attack quite practical.
Re: (Score:2)
Re: (Score:2)
::: Why do you think we created Triple-DES?
Because 56-bit DES was indeed weak. But aside from an exhaustive key attack as noted; do you know of any DES flaws? It seems like there are none. :::Supposedly the NSA made it more difficult to use differential calculus against DES by changing the S-Box permutations but it is still possible.
Let me check that out and see if that is indeed the case.
There are only two types of security... (Score:2)
We can start moving towards literally unbreakable security. And we really should for all high priority services. Things like book codes or modern versions of the same thing.
Encryption seeds into the terabytes.
Networks that are air-gapped and rely on proprietary network hardware that is simply different from everything else.
We need to push it farther. The NSA demonstrated that this is not paranoia. You make it theoretically possible and they're in.
Re: (Score:1)
Re: (Score:2)
Other ideas would be unique protocols... utterly distinct means of communicating information such that any system that doesn't understand the protocol wouldn't even be able to interface with it much less decode it.
Its akin to the Indian code talkers in WW2. You can use an encryption system like Germans or Japanese used... which the British and Americans broke respectively. Or you can use something like an unknown language to render the transmission unbreakable.
The unknown language can of course be something
Re: (Score:1)
I'm not trying to be offensive here, but I assume that you do not know too much about modern cryptography. Correctly applied, it is secure. Really secure. Successful attacks target the system that uses the cryptography, not the cryptography itself. Random number generators are a nice target. Systems running vulnerable software are nice targets. Targeting modern cryptography itself is usually a futile endeavour.
Languages can be learned. It may take a bunch of linguists a couple of years to get somewhere if t
Re: (Score:2)
As to modern cryptography being secure... the premise of most cryptography is that you've made something so complex that no one can sort it out. That is your security. It is security through complexity.
And I grant that it's probably secure in most situations. But my primary problem with it is that it's theoretically breakable.
We can make security systems that are theoretically UNbreakable.
As to a series of linguists breaking an unknown language. Wrong. Generally speaking, without a "Rosetta stone" or some v
Re: (Score:1)
Somehow I expected that the Voynich manuscript would come up. It's not a very good argument though. We don't know if the contents of that thing are even supposed to make sense. You can't decrypt /dev/random. In general, where you have data, you have context. That context helps deciphering the data, unless care is taken to make that impossible. And with "care is taken" I mean "cryptography is applied". If you make up a new language, it probably won't be a cipher that is better than encoding that information
Re: (Score:2)
As to not knowing if the Voynich manuscript is even language. That is the point.
That's how you know the security is solid.
Imagine for example if I write in chinese and you had no reference for chinese. You do not know how to read it and you don't know of any similar languages to aid in your decoding of the chinese.
You can't use a systematic code attack on it because it will never decode into a known language. You can't use the frequency of given characters to reveal words. There are no vowels or consonants.
Re: (Score:1)
A quick note to your argument about how with regular encryption you know when you have found the right key because regularities will appear: You can easily circumvent this*, by encrypting the data multiple times with different keys and possibly with different algorithms.
Or that there is nothing there that can be broken...
Re: (Score:2)
"Practical security" assumes you know the capabilities and knowledge of your enemy.
If you're wrong then "practical security" is insecure.
The point is that we can make things that cannot be broken. Cannot. Impossible. No amount of computer resources or human genius can breach perfect security.
And we can do it. It requires that we do things differently and it requires that the very term "practical security" be treated as a big red flag that there is a problem. "practical" means you know there's a vulnerabilit
Re: (Score:1)
DES is still secure? (Score:4, Interesting)
I thought DES had been abandoned quite some time ago precisely because there were attack vectors aside from brute force, i.e.: http://en.wikipedia.org/wiki/D... [wikipedia.org]
Re: (Score:3)
I thought DES had been abandoned quite some time ago precisely because there were attack vectors aside from brute force, i.e.: http://en.wikipedia.org/wiki/D... [wikipedia.org]
No, DES was abandoned because brute force became practical. It's still not easy, mind you, but it is within the realm of feasibility for well-funded adversaries. Yes, differential and linear cryptanalysis allow attacks that are in theory a little faster than brute force, but they're actually less practical than brute force, and even the theoretical reduction in work is small enough that if they were practical they wouldn't be much cheaper than brute force.
DES is still essentially unbroken, 40 years after
Security Without Obscurity.. (Score:2)
I couldn't help reading that as "Security Without Obesity" and that it's a hard to reach goal.
DES claim not commonly claimed (Score:2)
This