Quite seriously, this is exactly what the tech world needs - personally, I know that in terms of understanding of crypto I'm streets ahead of the average Joe, but orders of magnitude behind people who actually know the field. I'm certain I'm far from alone in that set, but the way the world's going means that we with the generalised technical know-how have a moral impetus to bring the rest of the world up to speed with the whys and wherefores.
Since the author is reading this: thanks. Read the first few lines and am already hooked. I have been looking for a long time, but most texts on crypto are either way below my level of understanding or miles above. You're a godsend!
"There are maybe 5 people in the world that may call themselves cryptographers"
Has anyone seen "streets ahead" being used by anyone else besides Pierce Hawtorn and the OP? I mean, is it widely used now? (I'm not native speaker, obviously)
So we went out on a limb and made these 1 minute layman video explainers on cryptography: http://gun.js.org/explainers/data/security.html , I hope they are useful. Anything incorrect?
Although this book claims a "Learn by doing" approach, I didn't find any specific assignments or data samples to facilitate that.
> The exercises accompanying this book focus on teaching cryptography by breaking inferior systems.
I wonder if there shouldn't be a software engineering class where people try to set up a secure web app, with their own homegrown algorithms and protocols, which is then attacked by a tiger team which includes a conspirator on the inside? Perhaps there are such classes now.
If you deployed vulnerable code, you'd see your stack fall over ~10mins later, along with an accompanying notice from the Penetrator Monkey that you've got work to do.
Something similar happens with code coverage. It's pretty easy to write tests that provide 100% code coverage yet still miss basic bugs. 100% code coverage gives you little more guarantee than "this code doesn't crash for naive inputs" unless the tests providing the coverage were well written - code coverage gives you no introspection to how good the tests might actually be.
In short, I agree that this would be a cool + useful tool. But it should come with a disclaimer that it's not a substitute for more thorough testing + verification.
As far as they go, maybe; but I worry that people don't appreciate the limitations. Making sure that someone can't code up an exploit against your system in half an hour is absolutely essential, but it's not the only thing that matters -- a serious cryptographer is also going to be concerned about "two years of coding and ten million dollars of computing power" attacks, which can be safely disregarded in CTFs.
In the sub-domain of web security, django.nV is such a "purposefully vulnerable Django application" that comes as companion to a websec tutorial: https://github.com/nVisium/django.nV
No disclaimer, I have no affiliation with the project, I just enjoy their work.
To have really capable people work on breaking your crypto for free, you have to be an insider. You become an insider by breaking other people's crypto. You can publish a break in an insider's crypto even if you are unknown. After you publish a few such papers, you become an insider and can publish your own crypto other people will spend their time trying to break.
People can learn the state of the art and develop an alternative to the common (NIST) choices which are no worse, but also no better. Some of those are blessed as "national pride ciphers" (GOST, Camellia, SEED, etc.).
Making a secure encryption algorithm requires a lot of presence of mind, and a lot of industry knowledge. If your threat model is incomplete, you lose. If you forgot one tiny thing at one tiny point in the algorithm, you lose.
If you don't have people checking your work, how do you know? If someone is determined to break your encryption, they are capable of spending a lot more time analyzing it than you spent building it. And they only need to find one mistake.
It's definitely better to use the tools that experts have spent lots of time, lots of breadth of knowledge, and lots of depth of knowledge inspecting.
A better question to ask is, how easy is it to break the protocols and the software using the protocols? We have secure ciphers. Those aren't where the problems in computer and network security lie.
Is there a general way to attack naive ciphers?
I fall of at even a proper Vigenère cipher, although I guess I could hack together a terribly inefficient python script to test all options and then print them line by line and start visually scanning for patterns :-/
If you go this direction you will find much more applications prepared for Capture The Flag competitions. Some people are even posting walk-throughs how to hack and fix them. It is very interesting & hard.
Strength training and general athleticism alone too will often allow you to win over someone who practices a martial art that is purely focused on striking, especially one of the more ornamental ones. Hard to win against someone that can just pick you up and slam you on the concrete ala Quinton Jackson.
Which aids in the analogy.
If you restrict yourself to aikido techniques and your attacker has no such reservations, you have to be extremely good.
Good for the analogy.
I think it would be a mistake to give up on self-defense in general because of that. In any case, you have to go into it knowing it's not a guarantee, it just increases your odds.
Good points for the analogy.
That is all there is to it.
Some examples here https://www.youtube.com/watch?v=C_SB0TqvUb8
E.g. even if RSA is (currenly) safe, as well as its primitives and common configuration... rolling your own implementation will probably be subject to timing attacks.
The conspirator is there to teach about Defense in Depth. Systems that rely on just 1 "impenetrable" membrane tend to be brittle. Their failure is catastrophically sudden and complete, like glass breaking. Glass is way harder than steel, but steel structures are much more robust, because steel's ductility allows for partial failures and continued resistance/integrity.
Your security is either sound or broken
What about "Defense in depth?"
Software is not the real world where things bend. If a barrier is sane, it will stand, nobody will break it. But no matter how many non-sane barriers you add, you can not turn them into a sane one. The only thing you will achieve is to increase your system complexity and get more bugs as a result.
All the others are about making the effort required greater than the will to get there in favor of usability.
All the standard libraries stop at "miniscule effort for a state".
And states aren't even "the big boys" anymore.
RSA is a simple formula. takes a bit of fiddling and skill to get BigIntegers working. but anyone who passed highschool algebra could roll their own. in fact many high schools even set it as homework.
timing attacks you say. erm, not remotely connected.
Rather than putting the rest of us at risk by putting zero value on the security of anything you make and guessing someone [a spook] will do it for you, why dont you recommend everyone takes some time out to at least learn the basics.
Yes, there are several "mines" you need to be wary of.
But they all pale into insignificance compared to linking openssl and thinking you are done.
Fine, I'll trust your overwhelming evidence instead of the many timing attacks described against RSA implementations.
padding -> irrelevent to an RSA public key, everyone has to know the exact modulus and product, even the bad guys (although I recommend keeping public keys relatively secret)
timing -> irrelevent to an RSA public key, there is nothing you can get from how long it takes to decrypt or encrypt even 1024 bits of data (which is more than most impliementations even send), sometimes the exact same data will take 1ms, sometimes 100ms, it depends what else the machine is doing at the time.
Firstly, I'm a real, honest-to-God cryptographer. I don't know if there are any particular people you had in mind whose recommendations you'd like to see, but there are a few HN bigwigs who'd probably be willing to generally endorse it :-) Also, it's been posted on HN a few times before, so it's had some scrutiny. That doesn't mean I don't make mistakes, but generally speaking, an active reader should be OK.
The other thing is in the way the book is structured. I teach you to break crypto; so when I say something is broken, I prove it by showing you how to break it.
Finally, the goal of this book is absolutely not to help you implement DHE. In an ideal world, the primitives we offer people are hard to misuse. Crypto 101 then only exists to satisfy programmer curiosity. It is not a replacement for a traditional academic education that will help you design new primitives; it also doesn't show you how to write secure implementations. However, Crypto 101 is still useful beyond merely satisfying curiosity now, because most cryptographic libraries _do not_ provide that easy-to-use API. Using regular hashes for password storage, various forms of broken AES-CBC (unauthenticated, key=IV, static IV...), et cetera are very real problems for real code, and Crypto 101 teaches you how to avoid that minefield.
I'm also working on the "better, more accessible" crypto part, but I only have so much free time :)
Separately with latacora I suggest that you wrap in some ongoing residual that carries on far past the 'eventually you staff your own security team' phase (as added insurance for 'leadership').
My g/f is getting interested in this sort of thing and she'll find this thrilling.
Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design your protocol, but use a reviewed protocol and implement that. Finally, step -2 is to not implement a protocol, but rather use a reviewed implementation of a fitting protocol.
This isn't sarcasm and I don't mean to attack you.
If "crypto is for cryptographers" is your stance I think you're doing yourself a disservice. Understanding crypto, as in learning the foundations of it, is important for everyone. Having a good grasp of cryptography helps with making decisions in your code base w.r.t to how you use cryptography primitives and tends to help you in identifying places where it's gone wrong.
I agree that it's easy to get these things wrong but I don't think that's a very good reason not to try to write or read up on the subject. And yes, it's possible that what you get taught might have holes too. But it's easier to fix these holes, for example by having discussions around the topic with others and validating what you're being taught, than acquiring the knowledge to begin with.
Now the author in question (lvh) is also known for their contributions to caesium (Clojure implementation of libsodium/NaCl) and Python Cryptographic Authority's cryptography library. They've got some solid chops in the area but make of it what you will.
That said, rolling your own crypto should be left to cryptographers with extensive peer reviewing and so on.
Engineers working around crypto that will be responsible for anything important, even doing seemingly simple things like feeding the entry point a password, need to either have their code audited by someone with experience here, or be a person who could audit it. This is because there are so very many ways that seemingly inconsequential things (function timing, hardware behavior in the face of voltage manipulation, nonzero-ed memory in deallocated buffers... and these are the more obvious things) that can lead to a break.
And that's really only a starting point... this stuff is hard. I won't try to write it other than for my own amusement.
Also, if you're ever interested in something.. find a protocol in a language, and try to refactor it, but first create a bunch of test cases, and make SURE to include unicode characters, etc in any strings you're testing, high byte characters are often missed as a use case, and it gets weird.
Getting multiple systems in multiple languages talking can sometimes be frustrating to say the least.
Or how about the whole Dual_EC_RBG backdoor fiasco? Yes, there was criticism right from the start, but it was adopted and used widely as far as I know. Heck, Dual_EC_RBG was only ousted in 2013:
"The ANSI X9F1 Tool Standards and Guidelines Group which discussed the backdoor also included three employees from the prominent security company RSA Security. In 2004, RSA Security made an implementation of Dual_EC_DRBG which contained the NSA backdoor the default CSPRNG in their RSA BSAFE as a result of a secret $10 million deal with NSA. In 2013, after the New York Times reported that Dual_EC_DRBG contained a backdoor by the NSA, RSA Security said they had not been aware of any backdoor when they made the deal with NSA, and told their customers to switch CSPRNG."
Besides, I think it's a good learning exercise to try to implement cryptographic primitives based on existing implementations. My opinion is that such language would dissuade people from even trying to design one for fun.
Disclaimer: do not design your own crypto primitive for production use.
I do agree that learning crypto is a good thing, because it gives you an idea of what your primitives should do, and when it is appropriate to use them. People should always refrain from using their own home-grown crypto, however.
Study and experimentation are how you end up with recognized cryptographers.
This very sensible attitude of "Use the recommended library with recommended settings" seems to get pushed to the point where it becomes "Don't bother learning". I don't think it's intentional of course.
I couldn't agree more. I think the fact that we have so much crypto foot guns available is a UX issue that we should address. Ideally, Crypto 101 would only be to satisfy one's own curiosity; not mandatory reading for anyone who wants to do something cryptographic. Alas, that's also not the world we live in right now. Realistically, plenty of crypto libraries will offer up e.g. unauthenticated AES-CBC. Then you probably want to know about some of the attacks on that, why you want a MAC, and where that MAC should live; if only to convince your coworkers that the concerns you have are real.
I think it's great, but it doesn't solve the protocol issue.
Even if you have good reason to believe that all available third party systems are vulnerable to one or another intelligence agency, using that would still be more secure than doing everything yourself, which you can't do properly (noone can do that without extensive review from a large community, so you definitely can't as well), and thus making a system that's vulnerable to everyone.
FWIW, I consider myself pretty well-versed on cryptography and although I haven't gone over this book with a fine-toothed comb (yet!), it looks very, very accurate to me.
I wouldn't expect that subtle implementation errors or even protocol flaws would get noticed on any news site, or even by contributors / co-developers or whatever.
(Disclosure, I took the class a few years ago)
For those reading:
How do you convince people that it's worth using best practices?
Is there a good heuristic to measure the value of something, when deciding how much time and money to spend on securing it?
What are good library/SaaS solutions to help build secure applications with less chance of shooting yourself in the foot, better UX and lower cost? (Keybase, etc.)
Although the video is marked 2015, the overlay at the start shows it's from PyCon 2013.
If anyone is interested in ECC, ars has a pretty good introduction .
 : http://arstechnica.com/security/2013/10/a-relatively-easy-to...
I should really remove that pre-release stuff. There's no useful point for "done", and it already includes most of the stuff I wanted to talk about.
I'm fine either way, just curious if this has changed drastically from what I had looked at previously.
"The entire Crypto 101 project is publicly developed on GitHub under the crypto101 organization, including this book: https://github.com/crypto101/book "
"The copy of this book that you are reading right now is based on the git commit with hash 3f89ec3 , also known as 0.4.0-22-g3f89ec3"
Then, looking at the commits, yes the book changed a lot since 2014: https://github.com/crypto101/book/commits/master
I should stop calling it a pre-release. There's no useful "done" marker. It includes most of the material I wanted to talk about, and has for a while. You should update the PDF though; as the other commenter mentioned, it does get updated :)
Well, maybe when there are no more "TODOs" ;)
Its free to read online but its also very reasonably priced. Its written by an engineer over at Cloudflare.
It's really encouraging to see this increased democratization of crypto not necessarily in the engineering of it per se but rather the awareness and understanding of it.
In the explanation of prop #1, he makes it clear that he is talking about the "avalanche effect," so it might be better to say that explicitly in the definition.
Disclaimer: I'm not a crypto person, so it's better if the author comments on this as well.
I think the book is great, by the way, especially the writing style and the choice of what to focus on. Thanks, lvh, for doing this.
Thanks for this, seems pretty useful.
There seems to be more attention to listing all the beasts in the cryptographic zoo than to the few fundamental tools required to really understand the mechanics (e.g. birthday paradox, PRFs, some prime number theory).
Sure, I can't spot anything fundamentally wrong and it all reads pretty smoothly, but calling this a "course" is highly misleading. If the intention is to guide people in selecting good crypto primitives, then maybe "guide" is a more honest word?
For those interested, I would strongly recommend to bite the bullet and dedicate time to Boneh's course on Coursera.
 I don't have any either
I could say "IND-CCA2" with a formal description, but in my experience that makes people's eyes glaze over. It's a lot easier to show them a bunch of reasonably-looking-yet-fatally-broken unauthenticated encryption to drive the point home. My target audience is curious programmers, not new academic cryptographers. If that's your criticism, that's absolutely valid. If you want to be the person to design SHA-4; this book isn't for you.
It's true that I take a different approach than Dan Boneh does. That's not a criticism: Boneh's course is great, it's just different. I think showing people how to break stuff is a useful educational tool. If your threat model is random web apps that have the letters "AES" or "MD5" in their code, I think it's a more effective one than a rigorous mathematical approach that will quickly dissuade the curious programmer.
I was under the impression he was formally educated in cryptography.
This ebook has been cited by many computer security university courses.
by Thomas Vidick (Caltech) and Stephanie Wehner (Delft University)
* In order to do QC you need an authenticated channel first. QC proponents hardly mention that or try to obscure it, but it basically means you can't have QC unless you already have some other secure cryptography.
* QC has severe practical limits. It needs a point to point connection capable of sending physical particles. That means: No Wifi, no mobile Internet and no connections over large distances. Given that these people recently started talking about a "Quantum Internet" makes this simply ridiculous.
It's probably insecure (these things get broken regularly), not practical for any real use case and total obvious nonsense to buy it, but I think there are some banks who thought they have some money leftover that they'd sink in such devices.