Well I personally find clarity in the history of things — they provide context and a narrative for the topic in question. You don't start a class on warfare with Afghanistan, for instance, or even WWII. It's worth going back to the beginning, if only for a cursory look at how wars were fought, how innovations came about and when, and which of them is still influential.
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.
History is great as a topic in its own right. But in my view, we already have lots of books that cover crypto through World War II.
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.
That is a pretty good list of recommendations, but I have a couple criticisms.
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.
> I come from a proud academic background and am sufficiently optimistic about humankind that I think it's a good idea to spread some knowledge around.
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."
For someone that is truly a beginner in cryptography it is helpful to understand at a very basic level how encryption/decryption works.
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.
There is zero cryptography value in spending more than 5 minutes on a Caesar cipher or ROT13. It's a shame that so many university courses on cryptography even waste such time on such topics. It would be like teaching times-tables in a course on calculus.
They are easy to understand and provide a venue to use the cryoptographic terms that the students should learn to use.
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.
Your comment would be better without the sad little barb, and with an actual example of nomenclature learned more easily from classic ciphers than from modern ones.
I suspect you didn't provide one because you don't have one. Prove me wrong.
One of the interesting things about classic ciphers is that (as far as I know) they're obviously insecure by modern standards.
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.
