About 2-3 years ago, I've watched all the lectures and then a couple of months ago I've watched them again to remember the details. It's joy watching Christof giving cryptography lectures.
I've worked through the entire Paar book (which is excellent), and I've made a number of attempts at getting through Boneh and Shoup (which is also excellent). I will say that there is a good overlap in content, but the Boneh/Shoup is solidly graduate-level, whereas Paar is a good and solid introduction for an undergraduate student.
If you’re looking for a less mathy introduction to cryptography, and a more applied ressource, check the book Real-World Cryptography. It wrote it over the last two years and a half and it just got released on Amazon a few weeks ago.
It teaches you about the cryptographic constructions that you run into all the time as a dev (https/ssl/tls, encryption, hashing, etc.) and gives you pointers on how not to mess things up (and what libraries to use, etc.)
I think the Bruce Schneiers Applied Cryptography is also really good. In fact it was written so that programmers would be able to implement algorithms from it.
Applied Cryptography is an excellent book, but it is very very old. Nearly 25 years old.
The foreword of the semi-recent (2015) "20th anniversary edition" (which appears to be a reissue of the 2nd edition) even recommends that you look for a more modern reference.
And one of the lessons of the last decades is that programmers should generally not be implementing their own cryptography unless that is their specialty.
In the link I posted you can read my point of view on this:
> The other two somewhat respected resources at the time were Applied Cryptography and Cryptography Engineering (both from Schneier). But these books were starting to be quite outdated. Applied Cryptography spent 4 chapters on block ciphers, with a whole chapter on cipher modes of operation but none on authenticated encryption. Cryptography Engineering had a single mention of elliptic curve cryptography (in a footnote).
I loved Dan Boneh's "Crypto 1" course on coursera about 10 years ago, and signed up for "Crypto 2" immediately. After a few years of postponement I unsubscribed from the emails, I guess it never happened :(
But I will take a look through this as it looks like it covers some of the same ground and then continues from there...
Is there any chance the LaTeX files available for this book? I'd love to try my hand at binding a physical copy but would need to get the page size to A5.
The book that "clicked" for me is: Cryptography Engineering: Design Principles and Practical Applications, by Ferguson/Schneier/Kohno (2015) [1]
In plain language it walks through what I wanted to know, in a modern and paranoid perspective, as a readable narrative, from the point of view that we want to design each of the basic crypto primitives ourselves.
Unfortunately, Cryptography Engineering (nee Practical Cryptography) is very much showing its age. It's a much better book than Applied Cryptography, but it's still pre-modern --- it spends a lot of time on outmoded multiplicative group asymmetric encryption, essentially excludes AEAD cryptography (which are the most important constructions in modern cryptography), and has weird advice on random number generation (that probably made sense before the world standardized on OS-level CSPRNGs).
It's easy to forget how old Practical Cryptography is, but: it predates Vaudenay's padding oracle attack.
My intro to cryptography was in a class by Victor Shoup. Highly recommend any of his books or materials. While I ended up not taking up cryptography professionally, I have fond memories from his course.
Anybody ever understand the attack game setups ? I felt like its a bit overcomplicated just to prove a contradiction. Also I am not sure if the metrics introduced like SSAdv and Message recovery advantage actually are used in places other than this book.
In my experience working through the first few chapters, I'll say that the attack game framework is pretty standard across lots of course materials from universities (at least the ones that I've found posted online). One thing that is not consistent is the notation used; it seems like there are multiple competing (but essentially equivalent) sets of notations used in attack game/advantage discussions.
I'm not sure what courses they had in mind, but Victor Shoup (one of the authors of the OP) has a book on number theory and algebra that goes over probability. That would probably be most useful if your goal is to study the applied crypto book.
The prerequisites are (self-reported) minimum, just calculus and mathematical maturity should be sufficient. I would check it out (it's free) and see if it's at an appropriate level.
Unfortunately I've yet to come across an introductory text or course on probability that is actually good :-(
What's your background? I just started A Programmer's Introduction to Mathematics because I also got stuck on math when I was previously studying cryptography. Not sure if it will actually solve my problem but so far seems like a great place to start.
I was just looking at resources for a complete beginner to get started with Cryptography for Infosec/CyberSec and this book topped all the recommendations. Hoping to see it updated soon.
I'm just finishing "Cryptography: A Very Short Introduction" from the OUP series. I found it to be a useful starting point even though (as the title says) it does not go into much detail, and it is a bit dated as well (currencies are not mentioned). It does, however, cover fundamentals that you can supplement with videos and other texts.
I never really understood the appeal of nerding out on cryptography. As soon as you get it in your mind to do some fun innovating people tell you (correctly) to "never roll your own crypto". Unless you're super talented at math (on the PhD level) and actually could roll it on your own then I don't really see why you shouldn't just abstract it in your head as a solved problem like modern day assembly code arcana (though I guess I'm curious about other peoples perspective).
I work in digital forensics. You wouldn't believe the misconceptions about "crypthgraphic hashes" and cryptography in general that are around in my area. If everyone took an intro course to cryptography that wouldn't happen as much as it does.
So there you have, one reason to take this course that is not "roll your own crypto" (which you should never do, unless you really really really know what you're doing. And even then you should check with a few people smarter than you to make sure everything is as you think it is.
You are right that the basics are often misunderstood but an Intro course this is not! Knowing what prime factoring is can be interesting if you like maths but definitely not required to understand on a practical level the difference between symmetrical, asymmetrical and things like CSPRNG vs hashing.
First, those people don’t materialize out of nowhere. They usually learn from this kind of content.
Secondly, the “don’t roll your own crypto” is general advice. It means “you’re probably trying to solve a problem that already has a battle-tested solution.
A lot of really talented people clearly roll their own crypto, otherwise we wouldn’t regularly have innovation in this field (although to be fair probably 90% of the ones that get traction are from DJB).
Finally, even if you should troll your own crypto algorithm, you probably still need to apply it to your problem domain. Understanding how to think about those attack vectors helps you understand the trade offs of which algorithms to pick. This makes the collaboration with a security team/security review more meaningful.
We don't regularly get innovation from generalists who pick up and figure out cryptography on their own. Daniel J. Bernstein is a professor of cryptography. Most of the innovations we see in cryptography come from people with graduate degrees in cryptography.
If you're someone like that, you don't need advice from random people on the Internet about whether you should practice in your field. Obviously, you should. But if you're someone who mostly spends their time writing general-purpose software and just find cryptography super fascinating or morally compelling, you do need the advice, because the cryptography you come up with is likely to get somebody hurt.
Of course you need the advice. If you're going to be working with cryptography it never hurts to know just a bit so that you can have an intelligent conversation with cryptographers.
However, I'll challenge your assertion. I've never done a graduate degree in cryptography. That reading list however is a good grounding in the landscape of cryptography & doesn't cover more esoteric things that are really things that cryptographers focus on. That reading list is one I've learned by practicing over the years & making sure to diligently read the various descriptions of each encryption algorithm.
I think you're confusing developing new cryptographic algorithms and applying cryptography to day-to-day problems. DJB designs new fundamental cryptographic algorithms. Those cryptographic algorithms are part of cryptographic operations that solve common problem types (e.g. DSA type algorithms for signing/verification messages, Diffie-Hellman type algorithms for key exchange, symmetric algorithms for encryption, KDFs for key derivation, etc etc). This reading list is extremely helpful for a generalist who is given the task of "add security" to some project and needs to understand where to start: are they exchanging keys, are they signing messages, encrypting, etc.
Cryptographers may also work on new algorithm families (various zero knowledge proofs, etc). So for example, you probably have cryptographers at Signal who work on figuring out how to apply cryptography in novel ways to solve their business problems. However, it wouldn't surprise me at all if companies have generalists collaborating with cryptographers as that's generally what I've observed everywhere. Different skillsets are useful and provide different perspectives as long as everyone can mostly keep up with each other because a problem is usually multifaceted & benefits from being tackled from multiple angles at once.
This tends to be the first thing people say in response to "don't roll your own crypto". "OK, I won't design my own block ciphers". In reality, virtually all our cryptographic vulnerabilities come not from fatally damaged primitives but from they way they're hooked up together.
I think we generally agree but in practice those who end up writing the code end up being generalists. Therefore having good guidelines, tools, and trainings is invaluable even for them. Having a formal PhD in cryptography isn’t the only way to learn cryptography. That’s the beauty of science and engineering. The topics are available for many to learn independently of a formal degree. Similarly, a formal degree doesn’t mean you will actually do a good job either.
It's just not the case that most of our resilient, trusted crypto code is written by generalists. What happens instead is that specialists write code in libraries like libsodium, and generalists on successful projects go out of their way to use those libraries rather than trying to rebuild them on their own.
There are paths to cryptographic specialization that don't involve formal degrees, though it's worth mentioning that many of the best-known cryptography engineers have intense formal training. I'm not saying you need a PhD to do crypto work, but you need something.
(Just for avoidance of doubt: despite doing a bunch of work in cryptographic software security assessment, I do not myself feel qualified to do cryptography design, and avoid it for that reason.)
But the point you made above, about how cryptographic specialists can build the AES's and the P-curve specifications, and generalists can just implement them: that was false. It's a broken view of how cryptographic vulnerabilities emerge. The vulnerabilities are in the joinery, not in the primitives, and they are subtle and surprising, and if you don't study them you will re-introduce them by writing straightforward, sane code that uses well-regarded crypto primitives.
> I never really understood the appeal of nerding out on cryptography
Gaining an understanding of how it works can help you avoid some of the pitfalls when dealing with it.
IMHO I always work better when I understand what's going on at least one layer down from where I'm playing. Nerding out on it can also help you understand how serious some attacks are and how broken your systems might be.
Never roll your own is good advice in production. Knock yourself out for test systems, for fun and exploration, but if you have some 'fun innovating' that you think might be good for real world use, pay someone that knows their stuff to audit it before trusting it. That's just common sense when it's so easy to get wrong.
Even if you use existing implementations, you can still use them in the wrong way and really screw up. Knowing how to correctly use implementations and what mistakes to avoid should be required for anybody using cryptography and that takes some familiarity with the material.
Yeah, there's a lot of crypto that's specifically tailored to minimizing the effect of mistakes like IV-reuse and it's not solved, the primitives can't do everything, so it's good to know these pitfalls. This book is more theoretical than that though and there's probably better sources idk.
About 2-3 years ago, I've watched all the lectures and then a couple of months ago I've watched them again to remember the details. It's joy watching Christof giving cryptography lectures.