Similarly, with crypto, I think it's about understanding how and why cryptography emerged, and learning about the arms race it developed into as people went from decoder-ring level encryption to the present state of the art. Knowing when and why key exchanges were first created, how they were broken back then, why one-time pads are still useful in some circumstances, and so on I think contributes to a larger understanding, something that exceeds a technical one - and I also believe that will lead to better implementation (though I don't have much to back that up).
Also, there are interesting stories in there. Learning why Enigma was unbreakable, and subsequently how it was broken and the attending circumstances, informed as they were by politics and strategic warfare, is a lesson not in cyphers, but in cryptography. I think that's important, though obviously that is not OP's goal! I just think it should the way one starts — at the beginning.
The comment you responded to reminds me of my favorite quote of Alan Kay where he compares software culture to pop culture, and expounds on the importance of history to rise to the higher levels.
I was lucky enough to learn cryptography from Len Adleman at USC, and guess what he started with? Classical ciphers.
Edit: Fixed from "Code" to "The Code Book". Although "Code" (Charles Petzold), on a different subject, is also excellent.
Very little of it is relevant to modern ciphers. Some of it is even actively harmful, witness old advice about "RNG entropy depletion" and "stale keys" resulting in overly complex and failure-prone crypto systems.
What we need more of relevant, modern, best-practices-in-light-of-latest-attacks information suitable for careful, conscientious developers who have to build actual systems out of it.
Do you think it'd be a not-terrible idea for newcomers to focus entirely on studying this? http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
The recommendations are mostly low-level. None of them are wrong, but they put undue burden on developers to get details right. For example, the AES-CTR recommendation doesn't talk about nonce management, but this is critical to the security of the construction. Application developers should always use the highest-level cryptographic constructions they can get away with. As such, many of these bullet points could be replaced with a recommendation to use PGP or NaCl.
Also, the list skimps on random number recommendations. It talks a bit about how big numbers should be, but it doesn't discuss sources. This is really important as RNG is a weak point in many systems. Short answer: use /dev/urandom.
If you're interested in creating a production application that uses Crypto, you should use existing high-level systems, and learn how to minimize your own areas of vulnerability. (Similar to your link)
But some people enjoy algorithms, and enjoy playing with information. That's a different goal, and a different objective, and would understandably have a different reading list.
For example, I went through a period a while ago when I was really enjoying learning about the development of the Apple II. As part of that, I read through the reference manual, and enjoyed learning various memory locations and what they did (None of which I remember, fwiw..)
I had a fun and relaxing Sunday afternoon reading the manual.. But I wouldn't expect those "skills" in Apple II memory locations to be particularly applicable to modern application development.
If you want to write an app, use tools. If you want to learn for the sake of enjoyment, that's awesome! Just remember the historical context, rather than trying to re-implement older bad practices.
Is it okay if I ask somebody here to send me a copy?
This is a funny way of pointing out the arrogance in the opposing position: "You aren't smart enough to do this right (and I am talking to you specifically), so don’t even waste your time."
Using something simple as a Caesar cipher or ROT13 you can show how plaintext undergoes a transformation using an algorithm to create the cipher text and how that same algorithm is used to convert the cipher back to plaintext.
This simple idea provides the basis to discuss other cipher techniques (and their shortcomings); as well as provide an early example of symmetric-key algorithms.
Having to understand a complicated bit of cryptography while at the same time coming to terms with a big batch of nomenclature you haven't committed to memory is hard. Harder than I can handle anyway.
don't ever become a teacher.
I suspect you didn't provide one because you don't have one. Prove me wrong.
(I can think of two potential terms already.)
Most of the time what people want out of modern crypto is something called "semantic security" -- in other words, an attacker should not be able to learn even a single bit of the plaintext for any message, even if they are allowed to see the encryption of polynomially many chosen plaintexts (ignoring length, of course.)
What this means is that deterministic encryption schemes are all broken. Consider a game:
The attacker asks to see the encryption of messages a and b, receiving a' and b' as ciphertexts of a and b.
Now, the attacker is "challenged" with a new ciphertext of a or b, c. If the attacker can (with reasonable probability) distinguish which plaintext c is the encryption of, then the encryption scheme is not "semantically secure."
Notably, since our encryption scheme is deterministic, c = a' or b'. Therefore, with probability = 1.0 the attacker can distinguish which plaintext encrypted to c.
So, by modern security standards all deterministic (and therefore all classic, I think) ciphers are broken.
This is the sort of thing which is covered in the coursera class. Modern crypto is (usually provably) substantially more secure than what used to be used, and the kinds of techniques used to do modern crypto don't have much overlap with things like Caesar ciphers.