If you can't invert the function than one of the following is true:
1) You don't have a one-to-one mapping of inputs to outputs, which makes this more like the compression function of a hash function, but will certainly be weaker than optimal for the intended purpose (we could then talk about how much weaker, but at the very least we no longer have a pseudo-random permutation, and it's not even a proper pseudo-random function, which means none of our traditional block cipher proofs will hold as is).
2) The one-to-one mapping exists, but there's a hard problem making it difficult to invert, in which case you have invented a public key cryptosystem (highly unlikely)
or
3) The inversion is possible and not computationally hard, the designer just wasn't clueful enough.
There's also the possibility that the poster wasn't the designer, wasn't correct, and it is a plain ol' invertible block cipher.
Another ill-informed post. There's a difference between absolute security and computational security. We can easily build provable security schemes for confidentiality and integrity, where we prove computational security against all possible attacks. It's not as theoretically absolute as a one-time pad because there is a computational bound where there might be some technological breakthrough (but that's very unrealistic). Or, more likely, the very modest assumption made about the underlying block cipher will not hold. If someone ever says, "AES is broken", that basically will mean they proved that assumption doesn't hold... for AES. Honestly, that seems quite unlikely to happen any time soon, and until it does, the assumption is such that you have a provably secure scheme against all computationally feasible attacks.
This is an incredibly ill-informed post. A cipher that takes a 128-bit input (plus a key) and produces a 128-bit output is a block cipher, just like AES is a block cipher. This has nothing to do with a one-time pad.
First, no block cipher should be used in a mode where you encrypt plaintext 16 bits at a time, and that's it (this is called ECB mode). We DO however, have a ton of ways to turn a block cipher into a function that offers strong guarantees for both confidentiality and message authentication / integrity. These are constructs where we only have to make a single assumption, which is loosely that, given a randomly chosen key, an attacker will have no significant advantage in looking at an output and distinguishing it from a randomly chosen value of the same size.
Your comment about rotating keys doesn't even make much sense. Most network protocols (e.g., SSL/TLS) basically do that... every connection they end up choosing a different random key. This is basic key management, it has little to do with the block cipher, and it's something we know how to do reasonablyy well.
Everything in the Secure Programming Cookbook compiled without warning under gcc -Wall and the Visual Studio compiler (where appropriate) and received a reasonable amount of functionality testing. We tried pretty hard to get people to do third-party testing, but it's very hard to get people to agree to test so much code. So it's very likely that there are some functionality bugs, but as they're found, we update things on the web site. This is why when using the code, you should get the newest code base from the website and do your own functionality testing. Let us know if you do find bugs, so that we can update things...
Because the code is just as relevant to C++ programmers, and there's no way O'Reilly was interested in a separate version for C++. It's a market size thing. You can not care about the C++ portions and read around it easily. Look at the sample chapter... you'll see that exactly what I said is the case... it's pretty much straight C except in some rare, well-delineated places, and the C++ programmers will still be able to find it useful.
Just a typo... s/stack/heap at the end there, and it should all make sense.,Basically, any time you can overwrite a vtable entry, you've potentially got a problem... most C++ programmers do not understand this fact.
Not offhand. I've tried to get concrete information, and have asked various people who "should know" at various large organizations, including gov't and corporate. The answer varies widely. I think the reality is still greater than 20%, but the.NET platform (as well as VB apps not written for VB.NET) and Java definitely have significant market share as well.
Matt and I aren't quite that colorful, unfortunately! Spaf wrote the foreword, but the rest of the book is probably a bit more dry than if he'd written it!
Honestly, they've got some smart people in this space, there. They've really been making a large effort, and it takes time for stuff like that to pay off, particularly when they've got dozens of millions of lines of legacy code written before their big security push. That is, while they might have started to care about security late in the game, they're currently putting forward a huge effort. I'll reserve judgment until some unspecified future date.
No, I said you MISSED my point. Of course it's easier to write more secure code in other languages. There are better choices than C and C++ for most tasks. What I was arguing is that if you rely on C and C++ sucking as a crutch, then your programs are going to have security vulnerabilities in other languages, too.
That said, something like 20% of the code out there is written in C and C++ to this day, and that's not dropping off slowly. We did this book first because there's a market for it and because it's got all the low-level solutions people can use as a foundation in any language. Next up is Java...
We stick to a C77 subset where possible that works across both C and C++ programs. There are some C++-specific examples for C++-specific issues.
Mostly, the security-critical problems DO overlap, unlike your statement. C++ doesn't have massive problems with stack overflows the way C does, but trades it off for big problems in heap overflows (due to leaving all those function pointers around on the stack).
Anyway, go read the book and come up with a VALID complaint, please.
If only buffer overflows were the only security problem in software:-( Buffer overflows only take up a few dozen pages. Over half the book is using cryptography properly in applications. The Java cookbook will deal with a lot of issues that come up in J2EE environments, as well as the things that typically go wrong other than overflows.
Buffer overflows pick up a lot of publicity, partially because security-critical ones are usually easy to leverage into the ability to execute arbitrary code. Don't let that lead you to he conclusion that there are not other security risks to software that are significant.
1) All of the book's code is available on our web site. The web site is probably the right place to go to to get the code, just because we can update it when there are errata (and you don't have to copy it out manually if you want to use it).
2) This is an implementation-focused book. You're right to refer to other texts for architecture, and besides my other book, the Microsoft press book you recommend and David Wheeler's free online HOWTO are both excellent (though I personally think the O'Reilly entry into that space is poor). At the same time, we do end up covering many aspects of good architecture in the discussion. Providing the context for a good implementation requires an understanding of the architectural issues, at least to some degree.
3) We have had several people tell us that they find the book very useful for other languages as well. I think it covers a lot of low-level implementation stuff that isn't available in other books, and is useful as long as you can READ C code. If there's anything people want to see for other languages, etc., feel free to send us email suggesting it. We will have frequent updates to this web site with new content (at least monthly). Much of the content will be for other languages.
The authors split maybe $3 or $4 per book, and the book *might* sell 20,000 copies in its lifetime. Not bad, but not great, considering it's a 800 page book, and book-writing generally takes about 3-5 hours of work per page total. Let's just say that we didn't do it for the money...
You're clearly a troll, since I have said quite clearly several times that C and C++ make security problems easier to introduce. That is, I don't disagree with a single thing you say, nor has anything that I've written disagreed, yet you still are arguing as if I said "C++ is the most secure language ever!"
If you have a reading comprehension problem, and are not a troll, then try to understand that the point of the article was to show that other languages are less secure than people believe. People can take this information and still choose another language, or they can choose to use mitigation strategies in C or C++. If they do the later, let them know the risks going into it, because it surely is more risky. But there's no stopping some people, particularly those people developing operating systems.
Nice troll. Don't get pedantic about things that are obvious verbal shortcuts, otherwise you'll never learn anything (hint... since the standard library is part of the C standard, it's quite common and proper to call it part of C).
The problem *is* the core language's fault, though, and not the library's fault, because it doesn't do bounds checking. If it did, the library calls could be as shoddily written as you'd like. C makes it easy to write code with exploitable buffer overflows in it. In most other languages, it isn't even possible.
You seem to think I reviewed "Applied Cryptography" on the web site. I didn't. I briefly discussed it when reviewing another book. There are NO "difficult math symbols" in Applied Crypto. Modern Crypto has math, it just makes it accessible (contrast to the HAC, which is a phenomenal resource as well, but too mathy for many developers. Why you think I'm afraid of the math because I realize other people don't care for it is beyond me).
Finally, if you think that I'm an idiot just because I cite a flaw in Applied Crypto instead of bowing at the temple of Schneier, then you need to reevaluate your own religious decisions, because Schneier himself makes the same fundamental claims about his book in Secrets and Lies as well as Practical Cryptography.
You clearly have reading comprehension problems. The article clearly states that, while other languages are indeed more secure than C and C++, the difference isn't as bad as most people think, because other languages aren't as secure as people seem to think.
The point of the article was NOT to say "C and C++ are more secure than you think." If anything, they're less secure than most people imagine. So are all other languages, though.
Comments will go live when we have time to implement them (hopefully no more than a week... most of the infrastructure is done). Until then, feel free to email us... we'll actually respond and post changes / annotations if it makes sense.
The solution may be obvious once you understand the problem, but the problem itself is incredibly non-obvious to most people who just go about allocating memory happily without ever thinking too deeply about the implications. Most developers are far more worried about getting the feature of the day working to "waste" a lot of cognitive effort on such things.
I dunno about that. There's a lot of software being exposed on that server, just through apache. It wouldn't surprise me if there were some 0-day out there affecting one of those things.
Yes, but not in the way you'd think. It wasn't bandwidth. The blog is being stupid and creating too many connections to the MySQL database, which eventually stops accepting more. Kicking MySQL is a reasonable stopgap measure.
Re:Vision of security isnt as bad as ./ make it
on
Secure Programming
·
· Score: 1
IMHO, if your admin portal is susceptible to a practical password guessing attack, then there is generally far more that you could have done in your application design. One of the most obvious things to do is to reject any password that is easy to guess. But then there are plenty of good authentication schemes that don't use passwords at all, or use them only as one factor in a multi-factor system (such as a private key encrypted with a key derived from a password).
I'd definitely say that it's impractical for most developers to have in-depth secure programming skills because there's just so much to know and keep in your head.
Slashdot Mirror
If you can't invert the function than one of the following is true:
1) You don't have a one-to-one mapping of inputs to outputs, which makes this more like the compression function of a hash function, but will certainly be weaker than optimal for the intended purpose (we could then talk about how much weaker, but at the very least we no longer have a pseudo-random permutation, and it's not even a proper pseudo-random function, which means none of our traditional block cipher proofs will hold as is).
2) The one-to-one mapping exists, but there's a hard problem making it difficult to invert, in which case you have invented a public key cryptosystem (highly unlikely)
or
3) The inversion is possible and not computationally hard, the designer just wasn't clueful enough.
There's also the possibility that the poster wasn't the designer, wasn't correct, and it is a plain ol' invertible block cipher.
Another ill-informed post. There's a difference between absolute security and computational security. We can easily build provable security schemes for confidentiality and integrity, where we prove computational security against all possible attacks. It's not as theoretically absolute as a one-time pad because there is a computational bound where there might be some technological breakthrough (but that's very unrealistic). Or, more likely, the very modest assumption made about the underlying block cipher will not hold. If someone ever says, "AES is broken", that basically will mean they proved that assumption doesn't hold... for AES. Honestly, that seems quite unlikely to happen any time soon, and until it does, the assumption is such that you have a provably secure scheme against all computationally feasible attacks.
This is an incredibly ill-informed post. A cipher that takes a 128-bit input (plus a key) and produces a 128-bit output is a block cipher, just like AES is a block cipher. This has nothing to do with a one-time pad. First, no block cipher should be used in a mode where you encrypt plaintext 16 bits at a time, and that's it (this is called ECB mode). We DO however, have a ton of ways to turn a block cipher into a function that offers strong guarantees for both confidentiality and message authentication / integrity. These are constructs where we only have to make a single assumption, which is loosely that, given a randomly chosen key, an attacker will have no significant advantage in looking at an output and distinguishing it from a randomly chosen value of the same size. Your comment about rotating keys doesn't even make much sense. Most network protocols (e.g., SSL/TLS) basically do that... every connection they end up choosing a different random key. This is basic key management, it has little to do with the block cipher, and it's something we know how to do reasonablyy well.
Cool. Hey, if you've got time to do extensive reviews like that, send me an email if you're interested in helping on future books!
Everything in the Secure Programming Cookbook compiled without warning under gcc -Wall and the Visual Studio compiler (where appropriate) and received a reasonable amount of functionality testing. We tried pretty hard to get people to do third-party testing, but it's very hard to get people to agree to test so much code. So it's very likely that there are some functionality bugs, but as they're found, we update things on the web site. This is why when using the code, you should get the newest code base from the website and do your own functionality testing. Let us know if you do find bugs, so that we can update things...
Because the code is just as relevant to C++ programmers, and there's no way O'Reilly was interested in a separate version for C++. It's a market size thing. You can not care about the C++ portions and read around it easily. Look at the sample chapter... you'll see that exactly what I said is the case... it's pretty much straight C except in some rare, well-delineated places, and the C++ programmers will still be able to find it useful.
Just a typo... s/stack/heap at the end there, and it should all make sense. ,Basically, any time you can overwrite a vtable entry, you've potentially got a problem... most C++ programmers do not understand this fact.
Not offhand. I've tried to get concrete information, and have asked various people who "should know" at various large organizations, including gov't and corporate. The answer varies widely. I think the reality is still greater than 20%, but the .NET platform (as well as VB apps not written for VB .NET) and Java definitely have significant market share as well.
Even without variable arguments, a bad PATH can lead to security problems...
Matt and I aren't quite that colorful, unfortunately! Spaf wrote the foreword, but the rest of the book is probably a bit more dry than if he'd written it!
I sent at least one person there a free copy ;-)
Honestly, they've got some smart people in this space, there. They've really been making a large effort, and it takes time for stuff like that to pay off, particularly when they've got dozens of millions of lines of legacy code written before their big security push. That is, while they might have started to care about security late in the game, they're currently putting forward a huge effort. I'll reserve judgment until some unspecified future date.
No, I said you MISSED my point. Of course it's easier to write more secure code in other languages. There are better choices than C and C++ for most tasks. What I was arguing is that if you rely on C and C++ sucking as a crutch, then your programs are going to have security vulnerabilities in other languages, too.
That said, something like 20% of the code out there is written in C and C++ to this day, and that's not dropping off slowly. We did this book first because there's a market for it and because it's got all the low-level solutions people can use as a foundation in any language. Next up is Java...
We stick to a C77 subset where possible that works across both C and C++ programs. There are some C++-specific examples for C++-specific issues.
Mostly, the security-critical problems DO overlap, unlike your statement. C++ doesn't have massive problems with stack overflows the way C does, but trades it off for big problems in heap overflows (due to leaving all those function pointers around on the stack).
Anyway, go read the book and come up with a VALID complaint, please.
If only buffer overflows were the only security problem in software :-( Buffer overflows only take up a few dozen pages. Over half the book is using cryptography properly in applications. The Java cookbook will deal with a lot of issues that come up in J2EE environments, as well as the things that typically go wrong other than overflows.
Buffer overflows pick up a lot of publicity, partially because security-critical ones are usually easy to leverage into the ability to execute arbitrary code. Don't let that lead you to he conclusion that there are not other security risks to software that are significant.
Thanks for the good review. A few minor points:
1) All of the book's code is available on our web site. The web site is probably the right place to go to to get the code, just because we can update it when there are errata (and you don't have to copy it out manually if you want to use it).
2) This is an implementation-focused book. You're right to refer to other texts for architecture, and besides my other book, the Microsoft press book you recommend and David Wheeler's free online HOWTO are both excellent (though I personally think the O'Reilly entry into that space is poor). At the same time, we do end up covering many aspects of good architecture in the discussion. Providing the context for a good implementation requires an understanding of the architectural issues, at least to some degree.
3) We have had several people tell us that they find the book very useful for other languages as well. I think it covers a lot of low-level implementation stuff that isn't available in other books, and is useful as long as you can READ C code. If there's anything people want to see for other languages, etc., feel free to send us email suggesting it. We will have frequent updates to this web site with new content (at least monthly). Much of the content will be for other languages.
The authors split maybe $3 or $4 per book, and the book *might* sell 20,000 copies in its lifetime. Not bad, but not great, considering it's a 800 page book, and book-writing generally takes about 3-5 hours of work per page total. Let's just say that we didn't do it for the money...
It's easier to eke speed out of C, largely because there's no pesky security ;-)
If you have a reading comprehension problem, and are not a troll, then try to understand that the point of the article was to show that other languages are less secure than people believe. People can take this information and still choose another language, or they can choose to use mitigation strategies in C or C++. If they do the later, let them know the risks going into it, because it surely is more risky. But there's no stopping some people, particularly those people developing operating systems.
The problem *is* the core language's fault, though, and not the library's fault, because it doesn't do bounds checking. If it did, the library calls could be as shoddily written as you'd like. C makes it easy to write code with exploitable buffer overflows in it. In most other languages, it isn't even possible.
You seem to think I reviewed "Applied Cryptography" on the web site. I didn't. I briefly discussed it when reviewing another book. There are NO "difficult math symbols" in Applied Crypto. Modern Crypto has math, it just makes it accessible (contrast to the HAC, which is a phenomenal resource as well, but too mathy for many developers. Why you think I'm afraid of the math because I realize other people don't care for it is beyond me).
Finally, if you think that I'm an idiot just because I cite a flaw in Applied Crypto instead of bowing at the temple of Schneier, then you need to reevaluate your own religious decisions, because Schneier himself makes the same fundamental claims about his book in Secrets and Lies as well as Practical Cryptography.
The point of the article was NOT to say "C and C++ are more secure than you think." If anything, they're less secure than most people imagine. So are all other languages, though.
Comments will go live when we have time to implement them (hopefully no more than a week... most of the infrastructure is done). Until then, feel free to email us... we'll actually respond and post changes / annotations if it makes sense.
The solution may be obvious once you understand the problem, but the problem itself is incredibly non-obvious to most people who just go about allocating memory happily without ever thinking too deeply about the implications. Most developers are far more worried about getting the feature of the day working to "waste" a lot of cognitive effort on such things.
I dunno about that. There's a lot of software being exposed on that server, just through apache. It wouldn't surprise me if there were some 0-day out there affecting one of those things.
Yes, but not in the way you'd think. It wasn't bandwidth. The blog is being stupid and creating too many connections to the MySQL database, which eventually stops accepting more. Kicking MySQL is a reasonable stopgap measure.
I'd definitely say that it's impractical for most developers to have in-depth secure programming skills because there's just so much to know and keep in your head.