Reddit reviews Secure Programming Cookbook for C and C++: Recipes For Cryptography, Authentication, Input Validation & More
We found 3 Reddit comments about Secure Programming Cookbook for C and C++: Recipes For Cryptography, Authentication, Input Validation & More. Here are the top ones, ranked by their Reddit score.
O Reilly Media
Right. But don't be so quick to judge. =)
The issue is that there isn't anything much better out there. A lot of the issues with teaching C is C itself.
C it a very simple language, maybe too simple. A lot of the safety in C is difficult because C doesn't give you anything to get that right. The solution to this is being very good at it, know what you're doing and avoid the problems. Modularity barely is possible in C (it is only through simple means). Dynamicity is a pain. All of these things that other languages simply support out of the box, you have to go through major hops in C so you get them.
From what I understand, most uses of C today only exist when nothing else is applicable. That is, when they really need the sort of benefits you get from using C, because the language itself isn't that great.
You could write whole books on getting modularity right in C, on getting dynamicity right in C, on getting security right in C, and so forth. And in fact there are:
It goes on and on and on. The C standard library is extremely thin (in comparison to everything out there). How can K&R2 teach you how to write highly sophisticated programs if the most advanced stuff in the standard library is sorting? I'm being a bit simplistic in this argument, but it's not so much distant from the truth.
Author: scrottie
Content:
>[Someone asked this on /r/bitcoin ; I typed up a long reply and wanted to share it here so I'm not contributing there and not here.]
>That's a tall order there.
>Programming in C/C++ for security (crypto, correct memory handling, etc) involves avoiding a lot of pitfalls. Experienced programmers who have been working in C for decades routinely make them. Even if you were working on BitcoinJ (which might be a good idea -- they can probably use help keeping up now), there's still a lot to know.
>There's no substitute for experience. Working with smart programmers, you learn things from them in response to what you've done in code and what you're trying to do... but reading a ton of books won't hurt.
>Here's something that attempts to teach secure programming in C and C++: http://www.amazon.com/Secure-Programming-Cookbook-Cryptography-Authentication/dp/0596003943/ref=sr_1_1?ie=UTF8&qid=1452714907&sr=8-1&keywords=secure+c+programming+cookbook [disclosure: I'm a tech editor on it]
>That also has introductions to using crypto (secure hashes, signing, public keys, key exchange, etc) from C.
>Read anything by DJ Bernstein: https://cr.yp.to/ . He's one of the few people consistently writing secure C code, and he has written some great pieces about it.
>Find some good intrusion books that show you how to write buffer overflows. Even if you don't get really good at it, understanding the theory will eliminate a blindspot. A lot of corporate code is terrible (Cisco, Adobe, etc) because progarmmers are super focused on production -- cranking out code -- and never step back and gain this wider perspective. Their products are all sitting ducks and they're completely oblivious to it because they have no concept of how this works. They expect every string copy to work flawlessly with no implications or gotchas because they don't know about these gotchas. Similarly, DEFCON talks are online now days. The original stack smashing (related to buffer overflows) was published by 2600 magazine, ages ago, and titled Smashing the Stack for Fun and Profit, I believe. It's still relevant and still a good introduction.
>Hardening Linux from APress is another fantastic book that'll give you loads of insight into practical security considerations on a Linux machine.
>Unix (and Linux) were revolutionary, but it's easy to take the ideas and innovations for granted and forget about them. New programmers tend to assume that just because they're writing code for Unix on a Unix system, their code will magically suck less than IBM mainframe code, Windows code, etc. This fallacy leads to a lot of crappy code. From the smallest one-liner to the largest system, your code will benefit immensely from actually understanding the Unix philosophy. So read The Design of the UNIX Operating System.
>To become a skilled programmer capable of solving problems, you absolutely must study algorithms. There's a Damn Cool Algorithms tumblr or something somewhere. There are also large books. IMO, 70% of the battle is understanding the concepts (data representation comes first, trade offs, etc) so you don't need to study every popular searching and sorting algorithm -- just read about a bunch of cool algorithms and consult the table of contents of Introduction to Algorithms by Cormen et al. If the for loop over a set of data is your primary means of solving problems, you're doing it wrong. Trying to process twice as much data will take to-the-power-of-2 times as much time. There are better ways. Often solving new problems involves finding them. Bitcoin is very much about efficient representation of data and operation on data.
>Structure and Interpretation of Computer Programs will teach you to solve hard problems.
>Obviously, you can't do this all at once. It takes ten years to get really good at any highly specialized skill. Plan on reading these things over the course of the next five years.
>Original thread: https://www.reddit.com/r/Bitcoin/comments/40tmgw/best_piece_of_literature_to_study_in_order_to/
That's a tall order there.
Programming in C/C++ for security (crypto, correct memory handling, etc) involves avoiding a lot of pitfalls. Experienced programmers who have been working in C for decades routinely make them. Even if you were working on BitcoinJ (which might be a good idea -- they can probably use help keeping up now), there's still a lot to know.
There's no substitute for experience. Working with smart programmers, you learn things from them in response to what you've done in code and what you're trying to do... but reading a ton of books won't hurt.
Here's something that attempts to teach secure programming in C and C++: http://www.amazon.com/Secure-Programming-Cookbook-Cryptography-Authentication/dp/0596003943/ref=sr_1_1?ie=UTF8&qid=1452714907&sr=8-1&keywords=secure+c+programming+cookbook [disclosure: I'm a tech editor on it]
That also has introductions to using crypto (secure hashes, signing, public keys, key exchange, etc) from C.
Read anything by DJ Bernstein: https://cr.yp.to/. He's one of the few people consistently writing secure C code, and he has written some great pieces about it.
Find some good intrusion books that show you how to write buffer overflows. Even if you don't get really good at it, understanding the theory will eliminate a blindspot. A lot of corporate code is terrible (Cisco, Adobe, etc) because progarmmers are super focused on production -- cranking out code -- and never step back and gain this wider perspective. Their products are all sitting ducks and they're completely oblivious to it because they have no concept of how this works. They expect every string copy to work flawlessly with no implications or gotchas because they don't know about these gotchas. Similarly, DEFCON talks are online now days. The original stack smashing (related to buffer overflows) was published by 2600 magazine, ages ago, and titled Smashing the Stack for Fun and Profit, I believe. It's still relevant and still a good introduction.
Hardening Linux from APress is another fantastic book that'll give you loads of insight into practical security considerations on a Linux machine.
Unix (and Linux) were revolutionary, but it's easy to take the ideas and innovations for granted and forget about them. New programmers tend to assume that just because they're writing code for Unix on a Unix system, their code will magically suck less than IBM mainframe code, Windows code, etc. This fallacy leads to a lot of crappy code. From the smallest one-liner to the largest system, your code will benefit immensely from actually understanding the Unix philosophy. So read The Design of the UNIX Operating System.
To become a skilled programmer capable of solving problems, you absolutely must study algorithms. There's a Damn Cool Algorithms tumblr or something somewhere. There are also large books. IMO, 70% of the battle is understanding the concepts (data representation comes first, trade offs, etc) so you don't need to study every popular searching and sorting algorithm -- just read about a bunch of cool algorithms and consult the table of contents of Introduction to Algorithms by Cormen et al. If the for loop over a set of data is your primary means of solving problems, you're doing it wrong. Trying to process twice as much data will take to-the-power-of-2 times as much time. There are better ways. Often solving new problems involves finding them. Bitcoin is very much about efficient representation of data and operation on data.
Structure and Interpretation of Computer Programs will teach you to solve hard problems.
Edit: Obviously, you can't do this all at once. It takes ten years to get really good at any highly specialized skill. Plan on reading these things over the course of the next five years.