The course is free and takes 6 weeks long, and is very interesting if you had never dwelled too deep into security or crypto. There's also a new cryptography class that will be available in September of 2017 - https://www.coursera.org/learn/crypto2.
I have been enrolled in the crypto2 class for several years now. I hope they finally offer the course, but I have low hopes.
The only vulnerability of Tor, which heavily depends on cryptography, is timing analysis.
One of the most important lessons of cryptography is that it doesn't exist in a vacuum. Timing between messages and message sizes can be enough to end you.
David Brumley and Dan Boneh, "Remote Timing Attacks Are Practical." In Proc. USENIX Security Symposium, 2003. https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
Abstract
Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from an OpenSSL-based web server running on a machine in the local network. Our results demonstrate that timing attacks against network servers are practical and therefore all security systems should defend against them.
It's definitely completely relevant today. Find out what you want to do and check that list.
A few things I would update:
* password handling -> Scrypt or Argon2
* Client-server application security -> TLS or Noise
* Hashing/HMAC algorithm -> Blake2/prefix-MAC or KangarooTwelve/KMAC
* Fingerprint -> TupleHash
* key derivation -> HKDF or SHAKE or BLAKE2X
And of course for each of these items, if a NaCL/libsodium solution already exist, just use it.
Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong (in the context of those recommendations, I also didn't want to explain the difference between SHA-2's HMAC and Blake2's keyed hash MAC). And, of course, part of the point of recommending SHA-2 was to recommend against Keccak. :)
I don't think I actually made a key derivation or fingerprint recommendation. I like HKDF!
Depending on who that list is for I could agree with you.
This recommendation comes from the fact that I'm seeing a LOT of companies who want to have their own secure protocol on top of whatever protocol and end up re-inventing the wheel to avoid the bloatness of TLS. Noise is a good advice for these custom made protocols. I wouldn't replace TLS in the advice, but add a note: "if you really do not want TLS, there is Noise, but that's it!
> Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong
Agree, but if we want to move to nicer/stronger algorithms we must start recommending them at some point. I want to see a push for Argon2/Blake2/SHA-3 in general.
> part of the point of recommending SHA-2 was to recommend against Keccak
Ah well, Keccak is so interesting (not only for hashing) that I would be sad if it end up not being used in the next decades to come. If you're feeling this way because of the efficiency: that's why I recommended KangarooTwelve, if you're feeling this way because of the crappy spec: alright you win.
> I don't think I actually made a key derivation or fingerprint recommendation. I like HKDF!
What are you waiting for! :)
The more important bit here is that I was updating Colin Percival's recommendations, which didn't include a KDF or an AKE. :)
For pretty much any crypto task that a "run-of-the-mill programmer" is likely to run into, they've got you covered.
Secret key encryption: https://download.libsodium.org/doc/secret-key_cryptography/a...
Password hashing: https://download.libsodium.org/doc/password_hashing/
The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous.
Most people don't need SSL. Most people don't need a zillion choices.
Most people need a single choice that actually works and is resistant to programmer error.
I think Heartbleed's even an example? Apparently there's some TLS ping ("heartbeat") command in the protocol that I'm pretty sure no-one actually asked for or uses in their applications, but there it is in the code, and so you're vulnerable as an application author.
No, because the combination of how you put them together can make you vulnerable.
For example, if you are encrypting lots of messages that all have the same header, certain crypto algorithms can be made to leak the key.
Do you know which combinations those are? I sure don't by default.
The fact that an end programmer even has to think about this is the problem.
In any cryptosystem, the application programmer is the person who knows the least about crypto. If he has to make any decision, you can expect he will get it wrong.
For example, I thought they provided some facility for avoiding nonce reuse vulnerabilities by automatically generating pseudorandom nonces for the user.
But then I double checked their API docs and they don't do this at all! Argh!
Matthew Green's blog, A Few Thoughts on Cryptographic Engineering [1], has a wealth of interesting posts that are often aimed at explaining cryptography to a "technical but non-cryptographer" audience, and tend to be motivated by recent events in security/cryptography news.
[0]: https://www.amazon.com/Cryptography-Engineering-Principles-P... [1]: https://blog.cryptographyengineering.com/
Start at https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
[protected form] = [salt] + protect([protection func], [salt] + [credential]);Edit: or maybe something else from the editorial history of the document?
The code examples are in Python, but I plan to add pages in other languages.
I've also come to realize that one should take everything that SG says with a large table spoon of salt.
That sounds like the same problem password managers have. And yet they are still recommended over (re-)using your own passwords for each website.
Anything else? I don't really understand the extreme reaction he seems to get.
Steve has been on public record for at least the past 12 years weekly on Security Now explaining things clearly and carefully. I've learned a lot from him and am very thankful.
If he even makes a tiny mistake on a podcast episode about something he comes back with a correction the next week.
He's been sharing his knowledge and expertise generously and a lot of people like me enjoy listening to him for 2 hours every week.
If you have a criticism write it out properly.
The OWASP guidance is OK for a quick access to best practices, but insufficient for rigorous learning.
Cryptography takes time to digest the fundamentals and recognise how new concepts are both beneficial and, vitally, disadvantageous; sadly, there is no cheat sheet or quick fix.
Source: computer security PhD student.
* PyCon Crypto 101 - https://www.crypto101.io/ (and if you use Python, please use Cryptography library for encryption/decryption please, Python built-in provides sha and hmac already though, and please adopt your framework's security implementation whenever possible).
* Mozilla Web Security Guidelines - https://wiki.mozilla.org/Security/Guidelines/Web_Security
* Mozilla Secure Coding Guideline - https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
* Mozilla Server Side TLS - https://wiki.mozilla.org/Security/Server_Side_TLS
* Mozilla Intro to Cryptography (slide: https://april.github.io/crypto-presentation video: https://www.youtube.com/watch?v=bg32spD2mB0)
* Mozilla Web wiki - https://developer.mozilla.org/en-US/docs/Web (understand CORS, Cookies, CSP, etc)
* Google's course on security - https://google-gruyere.appspot.com/ (original course page has been taken down by Google already)
Book recommendations:
* The Web Application Hacker's Handbook
* The Tangled Web: A Guide to Securing Modern Web Applications (written by the famous Michał Zalewski working at Google, and lately known for developing the American Fuzzy Loop AFL which has been used for uncovering many new CVE bugs).
* Hacking: The Next Generation
* Securing DevOps (to be released soon)
Publications:
* USENIX - https://www.usenix.org/ (tons of free high quality conference talks, I like USENIX over ACM)
* Real World Crypto
Getting real
* Go find bug bounty program out there, many well-written posts how one discovered bugs
* Follow a bunch of security engineers / security-minded folks on Twitter (e.g. @matthew_d_green would be a good start)
OWASP is a great reference, you read it as an index page. But like others have pointed out, the Wiki is often outdated, but concepts almost always remain the same. Use multiple resources before implementing a solution, and never just copy and paste solution posted by others on Stackoverflow. Sorry for so many Mozilla stuff definitely there's some bias from me but I trust folks running the sec team there.
> The other Password Hashing Competition finalists (Catena, Lyra2, Makwa, and yescrypt)
These were promoted above PBKDF2; algorithms with few implementations. PBKDF2-HMAC-SHA-512 with sufficient iterations is typically robust, and has been scrutinized.
I personally prefer scrypt, but in lieu of a solid scrypt or bcrypt lib I wouldn't hesitate to lean on PBKDF2 over the others.
Argon2i was in the same boat but being in libsodium went a long way to reinforcing trust, although Argon2i and Argon2d should really have had distinct names.
Although PBKDF2 is more widely available than bcrypt or scrypt, it doesn't offer the GPU resistance that we need from a password hashing function. If you must use PBKDF2, make sure you use at least 100,000 iterations and a SHA2 family hash function.
To reiterate: PBKDF2 can still be secure. It's the least secure of the acceptable password hashing algorithms on this page, so we aren't going to provide any example code.
I should probably update it to use one of the more modern algos, but the availability of good bcrypt libraries makes it solid advice still.
Part of the point of the crypto challenges was to illustrate why people shouldn't work directly with low-level primitives, as a sort of antidote to the kind of advice OWASP gave out.
I'm not sure that the cryptopals chalelnges are the best way to learn exactly how you should be implementing everything, but I've found the knowledge that I gained from doing the challenges very applicable in my daily job and definitely helped further my understanding of crypto in a way that reading a book just couldn't do.
There is a theory that we practice on my team that you don't really understand something unless you try to break it. And this team regularly tells developers facts about their programs and systems that previously unknown to them.
I did the challenges years ago when you had to email in for them. Since then I can count at least five occasions where having done the challenges has allowed me to identify vulnerabilities in real-world crypto. I was usually able to recommend fixes that in theory made those codebases more secure. This is keeping in mind that I'm at best a hobbyist security researcher and just barely a professional developer.
I think there are about seven or eight people on Earth that I would trust to securely implement cryptography in their code. For the rest of us I'm happy with doing the best we can with libraries that make that easy (NaCl), and otherwise trying to find ways to break the thing. The cryptopals challenges help you do that, so that's where I'd recommend a developer start.
I see a lot of "don't use" but I don't see any "do use" for that case.
Underlock is a small Ruby library that helps with Encrypting/Decrypting of files and other data.
OWASP seems like a decent source for learning about security topics at a high level (particularly web app security).
NIST is also responsible for running https://nvd.nist.gov/ which is a great asset for finding CVE.
http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.7621r1.pdf
DISA has the "STIG's" for security configuration:
http://iase.disa.mil/stigs/Pages/index.aspx
The NSA themselves, the Information Assurance Directorate, had guides on hardening various things. There's one for deploying Chrome in the link below that also references STIG on Chrome:
https://www.iad.gov/iad/library/ia-guidance/security-configu...
It would be straight-forward for INFOSEC people to vet the NIST or STIG guides for content accuracy then host that copy on their own sites. Or produce similar guides as some do. Just important to target them at people of low knowledge or competence so they know exactly what they need to do. It's them whose hardware will become part of the next DDOS due to configuration error.
Fair points, shouldn't throw the baby out with the bathwater etc. But as a governmental agency, do they have the autonomy to avoid being similarly subverted in the future? Not rhetorical, I genuinely don't know how they are governed/if they can refuse the "help" of the 3 letter agencies.
Which makes me realize, the 3 letter agencies may have still benefitted by the Dual_EC_DRBG scandal coming to light - what they lost in a backdoor, they gained in a chilling effect on the spread of good crypto practices by staining NIST's reputation.
It could happen to anyone if it's about receiving bad advice from an authority with a conflict of interest. That's why the solution is to either produce good advice for each of the things they're talking about or vet their advice to see if it contains any problems.
"what they lost in a backdoor, they gained in a chilling effect on the spread of good crypto practices by staining NIST's reputation."
I never thought about that. I doubt they intended that but it might be a real benefit for SIGINT side. That's interesting enough angle I'm going to bring it up to regulars on Schneier's blog who discussed the NIST stuff a lot.