Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Security Without Obscurity

samzenpus posted about a month and a half ago | from the read-all-about-it dept.

Books 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.

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.

cancel ×

51 comments

First Rule of secure coding. (4, Insightful)

jellomizer (103300) | about a month and a half ago | (#47247753)

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:First Rule of secure coding. (2, Insightful)

Anonymous Coward | about a month and a half ago | (#47248169)

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 part of the code hides the door, the other secures it. That way, when (not if) someone does find it, it can't be used for ingress. An example of this would be port knocking and incoming ssh using RSA keys (and no other forms of authentication allowed). The port knocking keeps the sshd process hidden. The RSA keys combined with fail2ban keep the sshd as a means for entry secure if someone does find it.

The car equivalent would be a strong box that slides out from under the vehicle with a push of a button. An attacker might find the strong box, but it will take some time to either separate it from the vehicle or cut into the box to fetch the goodies in.

Re:First Rule of secure coding. (0)

Anonymous Coward | about a month and a half ago | (#47249389)

Port knocking is NOT security. For we hackers listen, and we will SEE your port knocking sequence. Then we use it ourselves. Forget the "back door". If you need a door into a password secured system, add an ordinary account for yourself. No "back doors" - they are never actually needed.

Re:First Rule of secure coding. (0)

Anonymous Coward | about a month and a half ago | (#47251127)

Port knocking is NOT security. For we hackers listen, and we will SEE your port knocking sequence.

You clearly have a lot to learn about security in the real world.

Using your logic physical keys or access codes/passwords are not security then, for "we hackers watch, and we will SEE your keys/passwords".

Re:First Rule of secure coding. (1)

GameofScones (3695999) | about a month and a half ago | (#47248303)

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’t audit everything else.

Re:First Rule of secure coding. (1)

kesuki (321456) | about a month and a half ago | (#47250005)

"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 followed specs or not. have a password generated to be impossible to remember and requires a hardware decrypter to reform the password but can do so in multiple ways with only the one true way remembered by you, and you're golden against attacks on your setup, which then allows you to run fast computers that maybe have backdoors that are completely blocked by your secure machine, which you know is secure because you did it yourself.

Re:First Rule of secure coding. (1)

GameofScones (3695999) | about a month and a half ago | (#47253183)

::if you can't audit 7mb of code you're retarded And if you can't reply without an insult....

Re:First Rule of secure coding. (1)

Qwertie (797303) | about a month and a half ago | (#47248371)

I would think that the first rule of secure coding is "leave it to the experts". For instance I've been following the mailing list of Rust. Now the folks making Rust are smart, but they say they won't have any cryptography in the standard library in the near future because they are not confident in their abilities to do crypto correctly. Because it's very easy to inadvertently leave a weakness in your crypto code, even if you're trying to implement a documented standard.

So the first rule: don't do crypto yourself. But of course, given a crypto library written by experts, you have to find a way to use it. So the second rule: be very careful how you use it. Learn the basics of crypto, like the importance of key lengths and salts; the difference between symmetric and asymmetric crypto; learn about some of the attacks that are used (MITM, known plaintext attack, phishing, fuzzing, there are many); consider integrating a password strength meter...

Because just because you yourself couldn't get in without proper authorization, doesn't mean an experienced cracker can't get in.

Re:First Rule of secure coding. (1)

jellomizer (103300) | about a month and a half ago | (#47248717)

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 to professional network won't have packets floating around, that can be sniffed.
Most hacks today take advantage of problems in the code, not decryption the data in mid stream. If you are designing a system encryption is the stuff you can put at the end. But secure coding isn't about crypto but about a solid program design.

Re:First Rule of secure coding. (0)

Anonymous Coward | about a month and a half ago | (#47251695)

I really hate to be a spelling asshole because your posts were good. But you did the same thing in two posts and it just screams out for correction. So here goes...

s/threw/through

Re:First Rule of secure coding. (1)

GameofScones (3695999) | about a month and a half ago | (#47253197)

::Crypto is only a small part of security. It in many ways is over exaggerated in its effectiveness. Well said!! Bruce Schneier has made that point thousands of times!

Re:First Rule of secure coding. (0)

Anonymous Coward | about a month and a half ago | (#47253627)

Ben, use quote tags. LOLing that your sockpuppet now uses two colons instead of three as if you think that obscures anything.

Re:First Rule of secure coding. (1)

flargleblarg (685368) | about a month and a half ago | (#47256265)

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 (2)

js3 (319268) | about a month and a half ago | (#47247811)

Maybe obscurity doesn't mater after all

Re:OpenSSL disagrees (2)

Artifakt (700173) | about a month and a half ago | (#47248343)

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.

Re:OpenSSL disagrees (0)

Anonymous Coward | about a month and a half ago | (#47249437)

Security through obscurity fails when it turns out that the (hidden) crypto has bad vulnerabilities. (Which might be discovered if it wasn't hidden in obscurity).

Similiar to soldiers in camouflage being trivially spotted when someone discover that they are trivially visible in UV or IR or when looking at them through a red filter or something.

Meta-review (4, Insightful)

MobyDisk (75490) | about a month and a half ago | (#47247831)

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:Meta-review (1)

psyclone (187154) | about a month and a half ago | (#47248297)

I also thought the review was overly wordy and hard to parse. For example:

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:Meta-review (1)

IsThisNickTaken (555227) | about a month and a half ago | (#47253117)

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:Meta-review (1)

benrothke (2577567) | about a month ago | (#47347307)

Thanks for the helpful comments.

Rumsfeldian (-1)

Anonymous Coward | about a month and a half ago | (#47247833)

" To date, no known flaws have been found against DES " No found flaws have been widely published, you could say.

Re:Rumsfeldian (2)

GameofScones (3695999) | about a month and a half ago | (#47248309)

DES has been around 30+ years and the statement does stand. Any academic who could have found a major flaw would be a superstar. The fact that no one has found it, internationally, shows how it was secure.

Re:Rumsfeldian (0)

Anonymous Coward | about a month and a half ago | (#47251629)

Sure, Ben.

Either Ben or Stapleton is missing something (3, Insightful)

DJ Jones (997846) | about a month and a half ago | (#47247877)

"To date, no known flaws have been found against DES" : Er, differential calculus? Why do you think we created Triple-DES? Because we like things in threes? Supposedly the NSA made it more difficult to use differential calculus against DES by changing the S-Box permutations but it is still possible.

There was a time when the NSA had integrity....

Re:Either Ben or Stapleton is missing something (2, Insightful)

Anonymous Coward | about a month and a half ago | (#47248059)

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:Either Ben or Stapleton is missing something (1)

benrothke (2577567) | about a month and a half ago | (#47250475)

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:Either Ben or Stapleton is missing something (0)

Anonymous Coward | about a month and a half ago | (#47251491)

DES only withstood the test of time against those without brute force power. It would have stood longer had the NSA not purposefully weakened it with short keys.

Re:Either Ben or Stapleton is missing something (0)

Anonymous Coward | about a month and a half ago | (#47248215)

You mean differential cryptanalysis. Has nothing to do with calculus.
But DES is highly resistant to differential cryptanalysis, thanks to the NSA. Triple DES happened because brute-forcing DES became practical.
Seriously, it's a lot easier to try out all 2^56 keys on your own machine(s) than to get 2^43 known plaintexts or 2^49 chosen plaintexts with the cooperation of your target.

Re:Either Ben or Stapleton is missing something (0)

Anonymous Coward | about a month and a half ago | (#47248311)

And DES was only brute forceable because the NSA purposefully shortened the key length.

Re:Either Ben or Stapleton is missing something (2)

GameofScones (3695999) | about a month and a half ago | (#47248247)

Bruce Scheneir wrote in his latest newsletter: The NSA is Not Made of Magic https://www.schneier.com/crypt... [schneier.com] Details of his below...but the point is...there is no conspiracy...DES worked when it was long enough. I am regularly asked what is the most surprising thing about the Snowden NSA documents. It's this: the NSA is not made of magic. Its tools are no different from what we have in our world, it's just better-funded. X-KEYSCORE is Bro plus memory. FOXACID is Metasploit with a budget. QUANTUM is AirPwn with a seriously privileged position on the backbone. The NSA breaks crypto not with super-secret cryptanalysis, but by using standard hacking tricks such as exploiting weak implementations and default keys. Its TAO implants are straightforward enhancements of attack tools developed by researchers, academics, and hackers; you can buy a computer the size of a grain of rice, if you want to make your own such tools. The NSA's collection and analysis tools are basically what you'd expect if you thought about it for a while. That, fundamentally, is surprising. If you gave a super-secret Internet exploitation organization $10 billion annually, you'd expect some magic. And my guess is that there is some, around the edges, that has not become public yet. But that we haven't seen any yet is cause for optimism.

Re:Either Ben or Stapleton is missing something (1)

benrothke (2577567) | about a month and a half ago | (#47250453)

::: 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.

Re:Either Ben or Stapleton is missing something (0)

Anonymous Coward | about a month and a half ago | (#47251527)

Why do you use ::: instead of quote tags? And lol at your sockpuppet GameOfScones where you use the same bizarre quoting.

There are only two types of security... (1)

Karmashock (2415832) | about a month and a half ago | (#47247971)

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:There are only two types of security... (1)

GameofScones (3695999) | about a month and a half ago | (#47249531)

:::We can start moving towards literally unbreakable security. Aside from 1-time pads...what u referring to?

Re:There are only two types of security... (1)

Karmashock (2415832) | about a month and a half ago | (#47249615)

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 you just invent for the purpose. But the point is that it doesn't explicitly decode into what you'd think it would decode into.

Part of what allows decryption programs to work is that they know roughly what the final message will look like... that is letters, words, sentences, etc. What if it doesn't decode into what they expect? What if it decodes into columns of numbers or mathematical proofs that when run through a separate translation algorithm output the fully decoded message.

The one time pad though strikes me as the ultimate encryption method. And its much easier to use with computers.

Imagine if I gave you a one time pad file that was about 4 gigabytes in size. No problem for a modern computer. And now we can transfer 4 gbs of secure messages back and forth. Obviously not idea for high traffic messages but for limited ultra secure messages... what could be better. It would only be breached if the enemy got access to the machine used to send the messages. And nothing is going to survive that.

Re:There are only two types of security... (1)

NearO (591410) | about a month and a half ago | (#47250701)

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 the language is odd enough, but it is doable.

Proprietary, undocumented protocols and file formats exist. People who reverse engineer them and write their own compatible implementations also exist. I have done that kind of thing a few times myself.

Proprietary protocols and the like are basically what is commonly referred to as security through obscurity. This is considered a bad thing.

On the other hand, we have modern cryptography. Properly implemented, that stuff is incredibly secure. Even if you have a bunch of linguists or mathematicians, they won't break it in a few years or even a few hundred years, likely. The situation is not really comparable to WW2 era ciphers at all. We have left those far behind.

Sure, it is possible but we will have some incredible, mathematical breakthrough with regards to integer factorization, but it doesn't seem likely to happen suddenly. Usually, the state of the art advances at a slower pace. Even quantum computers will still leave us with working symmetric cryptography and (somewhat more unwieldy and less studied) asymmetric cryptography intact.

One time pads are commonly cited as the holy grail, but they miss the point and are difficult to employ, even today. Cryptographic systems are not broken by attacking the cryptography. They are broken by circumventing it. To use a one time pad, you first have to generate it. For that you need a true RNG, or it will be no better than a regular stream cipher. If your randomness is bad, you will be vulnerable and there exist interesting attacks [arstechnica.com] that could subvert commonly deployed sources of entropy, such as Intel's RdRand instruction.

The second problem is exchanging the one time pad securely. How are you going to do that? Snail mail? It could get intercepted. Besides, if you have a way to securely share a secret with the person you are communicating with, you could just share a 256bit ChaCha20 or AES key and be done with it. The practical gain in security a one time pad would provide over those would be negligible.

It would only be breached if the enemy got access to the machine used to send the messages. And nothing is going to survive that.

There is a nice property good, modern cryptographic systems provide, which is called "perfect forward secrecy". It guarantees that communications that took place before an attacker gained access to the secret keys of a peer will still remain secure after the fact. I suppose you could achieve something similar by securely zeroing out the used parts of your one time pad, but then you get into the messy affair of how to securely delete data.

Re:There are only two types of security... (1)

Karmashock (2415832) | about a month and a half ago | (#47250929)

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 very clear frame of reference unknown languages are totally inscrutable.

Here's an example for you:
http://en.wikipedia.org/wiki/V... [wikipedia.org]

Linquists, cryptographers, super computers, etc have all taken a crack at this and failed. Its an unknown language... possibly a made one... and no one can read it.

More importantly, no systematic attack can decode an unknown language. Its not just hard... its literally impossible.

That is what I'm looking for here... security that isn't just good... but literally impossible to break. As in you don't need to patch the fucking thing five times a week. You can set it up once then let the collective intelligence agencies and hackers from now until the end of time attack it and sleep easy because you know they're not getting anywhere with it.

That is why I threw out book codes or one time pad codes as an example. They're unbreakable without the pad. As in NEVER.

And yeah, I understand that most of the breaches happen with the software and not the encryption... but that's just because that's the weakest link. You don't waste your time with the tough stuff if you can find something softer.

Added to what I said above, I think systems that are secure must be simple. Very simple. As in no more then a couple pages of code. Why? Because complicated code is code that can't be debugged. Keep it simple and you can make the code perfect. Total confidence that there is zero error. As in 1+1=2 perfect.

Next the security probably has to be very ridged. Not flexible at all. It has to work a specific way and only that way. This again is to protect against a hack. hackers tend to exploit unintended flexibility in programming. Don't build the flexibility in and keep the system simple enough that you know precisely how it will operate in any situation.

So yeah... maybe I wasn't clear before. I am talking about perfect security. The sort of thing you'd trust to keep out the literal devil.

Re:There are only two types of security... (1)

NearO (591410) | about a month and a half ago | (#47251659)

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 in an efficient way and running it through a cryptographic cipher.

Well. You could encrypt something and then map that back into a grammar and speakable words, but that's cheating.

That is why I threw out book codes or one time pad codes as an example. They're unbreakable without the pad. As in NEVER.

You also ignored all the issues those have and which I mentioned.

Today's symmetric ciphers commonly have key lengths of 128bit or 256bit and usually there aren't even purely theoretical attacks that are significantly faster than brute-force. If you have a cipher with very conservative safety margins, such as ChaCha20, and a key length of 256bit that is pretty much unbreakable without the key too.

For comparison, the estimated total number of fundamental particles in the observable universe [physicsoftheuniverse.com] is somewhere in the range of 2^265 to 2^282. Maybe you would be satisfied 384bit keys? "2^100 times more states to check than there are particles in the universe" has a nice ring to it.

but that's just because that's the weakest link. You don't waste your time with the tough stuff if you can find something softer.

No, that's because modern cryptography is so strong that trying to break it is pretty much futile. If the cryptography was a viable target, it would be targeted, because then you could break all the implementations at once.

Added to what I said above, I think systems that are secure must be simple. Very simple. As in no more then a couple pages of code. Why? Because complicated code is code that can't be debugged. Keep it simple and you can make the code perfect. Total confidence that there is zero error. As in 1+1=2 perfect.

Simplicity is good, I agree. However, many actual cryptographic algorithms are rather compact. AES is just a few pages of code. So is ChaCha20 [cr.yp.to] .

As I said before. The cryptography is not the problem. Usually it's not even the code for the cryptography. Granted, there have been some cases of sidechannel attacks, but those can be (mostly) avoided with proper care.

A perfect OTP implementation won't help you if your application is leaking random memory blocks (including your OTP) to an attacker heartbleed-style.

The sort of thing you'd trust to keep out the literal devil.

The devil applies "simmer in a pot full of literal liquid hell fire" [xkcd.com] cryptanalysis, I believe. Apart from that, 256 bits of security should be enough against that guy.

Re:There are only two types of security... (1)

Karmashock (2415832) | about a month and a half ago | (#47252269)

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.

Without a basis for understanding the language you will NEVER decode such a message. Ever. Not in a billion years with all the computing power of a universe.

You're ignoring my point which is that the cryptography is theoretically breakable. Where as the things I'm talking about are not.

We have nothing more to discuss if you're going to go into tape recorder mode and utterly fail to have an interactive discussion where you actually respond to what other people have said. Your argument fails at this... This is the sort of crap chat bots output when you say something they don't understand. They just keep going off on their own little direction like wind up tin soldiers.

Well very well... no offense... but you need to respond to people's arguments and not just ignore things you don't have an answer for hoping that people will change their argument to something for which you have an answer.

I am talking about perfect security. Your comment about key lengths demonstrates that you really don't understand what I was talking about at all. All the key length does is make decoding complicated. With enough computing power a brute force attack will break through any systematic encryption scheme unless that scheme is more then simply complex but inscrutable.

As to your point about getting things decrypted by torturing the people that encrypted it... well yes, that always works but the point is to make that a literal requirement.

And if those people are out of reach or unknown then the message will remain secure... and here is the point "forever".

Do not skip over that last word please like you did last time. That is my point and ignoring it will only lead you to make more false arguments.

Re:There are only two types of security... (1)

NearO (591410) | about a month and a half ago | (#47254671)

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.

That's how you know the security is solid.

Or that there is nothing there that can be broken...

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.

First something general about using human languages for the purpose of security.
1) If you invent a language, your vocabulary and grammar will basically be the key. Admittedly, it will probably be a pretty big key, but partial knowledge of the key will likely allow partial deciphering of the messages in that language.
2) Inventing languages for the purpose of security is not a well studied field. If you do it ad-hoc, you are unlikely to get a great result.
3) In general, when using human languages, similar messages will look similar. As information rarely exists in a vacuum (the Voynich manuscript pretty much does, yes), this may allow an attacker to make inferences about your messages.

To use your example of Chinese, consider the following scenario. You are using Chinese to communicate with a friend. In this world, Chinese is a language known only to you and your friend. I am a well funded adversary and capable of observing your general daily behaviour in a way that only requires communication meta-data and a guy who watches your house and one who watches the house of your friend.

On day 1:
You send your friend a message: æ'äçç¦ä½æ"ääç"èã
I observe:
- You clean the windows.
- You go buy things from the grocery store.
- You give your friend a phone call.
- You take a walk.
- Your friend goes buy things from the supermarket.
- Your friend receives a phone call from you.

On day 2:
You send your friend a message: æ'äfçäåååZçoeæ'æoeåäã
I observe:
- You take a walk.
- You chat with a neighbour.
- You call your mother on the phone.
- You go visit somebody.
- Your friend receives a phone call from somebody.
- Your friend goes eat at a restaurant.

On day 3:
You send your friend a message: æ'æoeåç¦ä½æ"ääç"èã
I observe:
- You buy things from the grocery store.
- You take a bath.
- You take an evening walk.
- Your friend receives a phone call from the person you visited the day before.
- Your friend goes swimming.

(Please go here [pastebin.com] for a copy where /. hasn't messed up the Chinese characters.)

By now, I will be able to make some guesses about the meaning of various parts of the Chinese language. If you communicate more, I will be able to refine those guesses. I suggest you mull over it a bit and see if you can come up with a few hypothesis yourself. And yes, it's proper Chinese.

You're ignoring my point which is that the cryptography is theoretically breakable. Where as the things I'm talking about are not.

I am not ignoring that. I merely hold the opinion that the difference in practical security is negligible. To reiterate the pros and cons of using OTPs instead of regular, modern cryptography:
+ Properly used, OTPs can be perfectly secure.
o This means, if you compare the security of an OTP with that of a conservatively designed cipher using 128bit keys, you have reduced the probability that your cryptography will be broken by a bit less than 0.00000000000000000000000000000000000001%.
o Using an OTP does not defend against attacks that circumvent the cryptography instead of attack it, which is basically all of them.
- You need a secure random number generator, which is not backdoored by the NSA and can quickly generate sufficient amounts of random data.
- You need to securely exchange OTPs with everybody you want to communicate with. This is hard, if you want to maintain the perfect security provided by the OTP:
* You cannot send unencrypted it over the internet. If you send it encrypted, it will be no better than using said encryption.
* You cannot entrust it to the postal service, because it may be intercepted.
* If you don't know your communication partner in person, even meeting up may not be secure as you might meet a similar looking adversary with a fake id card.
* Either of you might get "mugged" on the way to the meeting.
* You need to repeat this whenever you run out of OTP.
o Admittedly, exchanging keys for regular encryption faces similar problems, but there are some established techniques for verifying identities in a probabilistic way (e.g. the web of trust with PGP). If you are doing realtime communication with somebody already, it is probably sufficiently safe to quickly tell them a fingerprint or public key.
- You need to securely store your OTPs. For this you need heavy physical security. If you just encrypt them for security, they won't really be more secure than the encryption you used.
- You give up useful techniques such as Diffie-Hellman key exchange for a slight increase in security.
- You cannot transmit basically arbitrarily large amounts of data with a single key exchange.**

And if those people are out of reach or unknown then the message will remain secure... and here is the point "forever".

Do not skip over that last word please like you did last time.

My point is that we don't need it to last forever. It's enough if it lasts until the universe loses itself in entropy. Hell, it's probably enough if it lasts 500 years. Unless I become immortal, I suppose I would be fine with my secrets from now being revealed in 500 years. Might be nice for the historians then. It is with this in mind that I argue about the sufficiency of non-OTP cryptography.

For any (un)reasonable time span, 256bit keys are more than enough. Heck, if we go with 512bit keys, an attacker that turns every fundamental particle in the universe into a computer that works at breaking your key will still take longer to break the key than the universe has existed for so far.

You can use OTPs to achieve "perfect" security. Yes. It will be impossible to tell, which of the 2^(messagelen) messages is the correct one if you do not have access to the OTP. However, the practical application of OTPs is difficult and the gain in security is unlikely to affect anything in the real world.

As to your point about getting things decrypted by torturing the people that encrypted it... well yes, that always works but the point is to make that a literal requirement.

It basically is a requirement already. That's the reason the UK has laws that allow them to throw you into prison for not giving them your encryption keys. That's the reason the US government went and demanded that Lavabit hand over their encryption keys so they can get a Snowden's emails.

* In that case, your sequence and number of encryptions will become part of the key. At some point, structure will always appear. At the very least in the brain of the receiver.

** There are usually limits for the number of blocks or bytes a single key can be used with a cipher, but you can always negotiate a new one securely through your existing, secure channel.

Re:There are only two types of security... (1)

Karmashock (2415832) | about a month and a half ago | (#47256575)

"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 vulnerability but you don't take its exploitation as being likely. Why take those risks when we can just make the security perfect.

I'm not suggesting we observe the most paranoid security in all situations. But we should keep in mind that that is the gold standard and that everything else is a compromise. That way when system's planners know that a given system CANNOT fall to the enemy they know they have to use the gold standard security. Nothing else suits.

That security must have encryption that cannot be broken and a software/hardware system that is too simple and inflexible to hack.

An example might be our energy grid. You can't let hackers from wherever get into the grid and start causing brownouts.... or throttling a hydro electric dam up and down which might cause damage.

We have remote facilities all over the world that we must access and may of those systems should not be vulnerable to breach. When I say "should not" I mean literally impossible. We can do it.

Refusing to do so when its right there in front us is inviting Murphy to bend you over and have his way with you.

ISO (-1)

Anonymous Coward | about a month and a half ago | (#47247975)

I have seen certification exams where they ask what that acronym stands for.

Doesn't it stand for "burnable CD image"?

Re:ISO (1)

GameofScones (3695999) | about a month and a half ago | (#47248417)

Same org...different standard.

DES is still secure? (3, Interesting)

DomNF15 (1529309) | about a month and a half ago | (#47248025)

"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. "

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:DES is still secure? (0)

Anonymous Coward | about a month and a half ago | (#47248267)

Ruins the man's credibility as an authority on cryptography doesn't it?

Re:DES is still secure? (0)

Anonymous Coward | about a month and a half ago | (#47249173)

Ruins the man's credibility as an authority on cryptography doesn't it?

If there were attack vectors aside from brute force that were actually practical, it might...
AFAIK, the only attack vectors to DES impose additional requirements like known or chosen plaintexts and although are technically asymptotically faster than brute force, are heavily weighted on the space axis of the time-vs-space tradeoff so they are far-far less practical than brute-force search (which for DES's 56-bit keys, aren't really a stretch for computers anymore)...

Re:DES is still secure? (0)

Anonymous Coward | about a month and a half ago | (#47249885)

The man says no known flaws, then one is listed and you say that one doesn't count. Really, getting someone to encrypt a known plaintext is trivial. Just look at well known headers, done in one.

Re:DES is still secure? (2)

swillden (191260) | about a month and a half ago | (#47248323)

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 its invention. But the 56-bit keys required by the NSA are now too short to be secure. Triple DES, which is generally implemented using two 56-bit keys, for an aggregate 112-bit key length, is still considered to be quite secure. AES is a better choice at present not because it's noticeably more secure but because it's much faster.

Security Without Obscurity.. (1)

Blaskowicz (634489) | about a month and a half ago | (#47249705)

I couldn't help reading that as "Security Without Obesity" and that it's a hard to reach goal.

DES claim not commonly claimed (2)

NearO (591410) | about a month and a half ago | (#47250473)

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.

This is an odd thing to say. It almost sounds like an attempt at whitewashing the current Dual EC DRBG [projectbullrun.org] business by debunking a not commonly made claim about another cryptographic algorithm with a vaguely similar name.

It is widely known and accepted that the NSA strengthened DES against differential cryptanalysis, while also ensuring that the key length is short. They both strengthened and weakened it in different way. There also are [wikipedia.org] attacks against DES, which are, in theory, faster than brute force.

Giving the number of tries necessary to brute force a 56bit key is also kind of odd, since that is a key size that can actually be broken these days without too much effort. What's the point in trying to wow the audience with big numbers in that case? Seems misleading to me. Granted, that may have been just the reviewer and not be part of the actual book.

Fuck me with a spoon (0)

Anonymous Coward | about a month and a half ago | (#47251657)

Ass goblins.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...