Ask HN: What cryptography book do you recommend for reading with 10 year olds?
We are looking for a Cryptography book recommendation to read with our 10 year old who loves making up his own ciphers. He loves reading adult math and science books with us at breakfast like Ignition!, Humble Pi, and The Hunt for Vulcan. All of the kids books that we've found are just puzzles, but I don't want to get something way over his head math-wise. A good history with basic theory behind the different types would be perfect. Thanks!
- _Codes and Ciphers: Secret Writing Through the Ages_ by John Laffin
- _Codes, ciphers, and secret writing_ by Martin Gardner
There was another book on alphabets/letterforms and ciphers --- pretty sure it had a cover designed by Oscar Ogg, but blanking on the name and can't find it.
While searching online for that found:
Secret Writing: An Introduction to Cryptograms, Ciphers, and Codes by Henry Lysing and John L. Nanovic
Cryptography adjacent (it's about the difficulty of deciphering a dead language), but H. Beam Piper's novella "Omnilingual" really should be part of the grade school canon --- lightly updated version at:
One of the books that got me interested in cryptography as a kid was Artemis Fowl! It might be too simple for him now, but the gnommish (glyph substitution cipher) on every page was really fun for me to figure out.
Lemony Snicket’s A Series of Unfortunate Events have some of this too, especially the Unauthorized Autobiography. My little brother once encoded a secret message into one of his essays on a standardized test using the Sebald Code!
It's not directly a cryptography book, although it includes some basic cipher guidance, but I LOVED the Usborne Spy's Handbook as a child. It's still available now. I'd thoroughly recommend it - I completely wore it out as a kid, so much so that the book fell apart, leading me to re-purchase it as an adult for nostalgia. Genuinely useful book! I still use some things from it, like estimating crowd sizes.
I would suggest Real-World Cryptography by DAVID WONG. It has good introduction covering basic primitives like various hash functions, MAC, KDF, then sym/asym, and so on, all the way to PQC and protocols design. A nice intro book, maybe your 10 y.o. will find it interesting.
P.S. In fact, I was going to send that book to my friend's son who is about same age, and who got some sudden interest in cryptography recently. So it is safe to say that I am now aware of at least two 10 year olds who have interest in Cryptography. I feel a bit surprised, but in a good way :)
He started with inventing his own alphabet and language as he was learning to read and write, which eventually evolved into reinventing the Secret Decoder Ring with increasing complexity, so we want to encourage him in his adventure.
In Code by Sarah and David Flannery (https://www.amazon.com/exec/obidos/ASIN/1565123778/donhosek). I would usually target this at bright high school kids, but I think that your kid might be a good fit for it as well from what you describe. Sarah was a high school student learning about cryptography from her math professor dad (David), and presents a great overview of cryptography from Caesar to modern public key cryptography (she came up with an idea using the fact that matrix multiplication is hard to invert for a cipher scheme although it turned out that there was an easy crack for her matrix-based cipher).
I was trying to recall the name of this book just the other day! All the recent CA news had reminded me of it and I couldn't remember the name, but I remembered the cover.
In high school, we had to pick a math book to do a book report on. There were lots of people picking books like Flatland, but I ended up with "In Code". I actually thought it was a programming book because of the word "code" in the title. Turns out I was wrong, and I got exposed to learning cryptography as a high schooler! And since it was a book report, my reading culminated with me fumbling through explaining public key cryptography to my math class.
Fred Wrixon's Codes and Ciphers was fun for me and a friend around this age, and it looks like it's been updated in the decades since.
One angle from which it's fun is just learning operations you can do on text (and text represented as numbers). Empirically it turns out just Shannon's "diffusion and confusion" and lots of rounds gets you far in symmetric cryptography, which we can see from a lot of simple RAX primitives working fine. But it's nice for reasons outside cryptography to get a feel for the zoo of other things you can do, what offers diffusion and nonlinearity, how you can ensure a function's reversible, etc.
If you did one topic from public-key land, I think Diffie-Hellman is easier to understand than RSA without much build-up: it makes sense from the basic properties of exponents (ones modular arithmetic doesn't change), and modular arithmetic connects to fun stuff about the primes. Merkle hash signatures also make sense with just symmetric cryptography, and are post-quantum-resistant!
I hadn't really thought about how you'd even approach PQ encryption, but maybe ECC-based McEliece is cool? You can get a feel for it even without detail on the hard decoding problem, and error correcting codes are their own interesting topic.
I don't have a book recommendation but in terms of topics, I would definitely suggest Shamir's secret sharing scheme as a good one to cover. It is pretty accessible mathematically (if you stick to prime finite fields) and "different" enough to the usual conception of a secret code or cipher to make it fun to play around with as well.
It teaches the basics of information theory and computability with a series of lessons and paper games (including some ciphers and why they work). All of my kids went through it, and had fun doing it.
Not a book but you could construct a little walk through some historical crypto as fun games to play. Caesar cipher, Vigenere cipher, one time pad, then learn about primes and make some repeating keys..you could do a super simple matrix example to make tiny DES s-boxes. I bet claude could come up with some games / fun little exploration things to do together, and you and your son could do a lot of fun motivating math together. You could anchor it with rewards like pictures of you and your partner or some family history or stuff that feels like a treasure hunt.
Mine are out of the house, but I had a few who might have really liked doing something like this.. could make a nice Christmas present, the first mysterious letter..
Introduction to Modern Cryptography by Katz and Lindell is from a pedagogical perspective one of the best-structured textbooks I've ever read on computer science topics (and in general, but my exposure to textbooks is a biased sample). It goes into the foundations of cryptographic theory and gives a good basis for understanding and contextualizing even advances that have been made since its publication. I think most children can grasp difficult material if an adult that's good at the meta-skill of teaching is helping them with it via individual attention
"I think most children can grasp difficult material if an adult that's good at the meta-skill of teaching is helping them with it via individual attention"
That's how we feel too and they appreciate being given that chance if we don't push.
The Codebreakers is a fantastic book and I highly recommend it. I don't know what I think of it for a ten-year-old, it's been a while since I've read it, but my memory is that it is certainly mathematically accessible, but its length and depth may make it daunting, as it probably exceeds the attention horizon of a typical ten-year-old by an order of magnitude or two. But in chunks it could work, and for an adult it's fantastic.
It does assume a fair bit of historical context knowledge, though, much of which probably exceeds 5th grade. Probably 9th graders would have it easier as far as, e.g., familiarity with WWII, etc.
There was a television series (British?) featuring some of the tales mentioned in David Kahn's book. The TV series could be a good introduction for children. Another book of interest may be Crypto by Stephen Levy - Viking Penguin 2001. Which relates how "rebels beat the (U.S.) government - saving privacy in the Digital Age".
Highly recommend 'The Code Book by Simon Singh'. Simon also runs a math circle online called parallel circles from the UK, that is free to attend and is fun for kids.
For a 10 year old I would highly recommend Martin Gardner’s “Codes, Ciphers, and Secret Writing”: https://a.co/d/05rZPKiH
It’s a slim volume that focuses on historical and fictional ciphers. It stars with simple shift ciphers like Caesar’s cipher, progresses to more complex substitution ciphers with examples from Sherlock Holmes and Edgar Allen Poe, then covers polyalphabetic ciphers like Vigenère and Playfair. It covers basic cryptanalysis and has practice riddles and cryptograms throughout. It even has a chapter on a variety of ways to make invisible ink, which is often an object of fascination for children around that age!
My 5-yo is enjoying Codes and Ciphers by Sean Callery (ISBN 978-0061374074) which I read when I was about 10. It’s a very pragmatic book: it has oodles of historical codes and ciphers and covers all the basics that you can do with pen-and-paper. Not as much of a history book as The Code Book—I also highly recommend that one.
As a 10-year old, my introduction to cryptography was from reading a few novels by Jules Verne:
The Giant Raft or 800 Leagues On The Amazon
Mathias Sandorf
A Journey To The Centre of the Earth
After reading those, I played with the ciphers described there, i.e. I made and used the transposition grid from Mathias Sandorf and I used various Vigenère ciphers, like that from "800 Leagues On The Amazon".
Due to the interest generated by those stories, a few years later I read various textbooks about modern cryptography.
The book "Applied Cryptography" by Bruce Schneier is now somewhat old, so it is no longer up-to-date, but it is written in a style more accessible for newbies than most textbooks about cryptography, so I think that it would be adequate for a teenager who is good at mathematics.
When I was a kid and read 800 Leagues I proceeded to make a whole encryption IDE in Visual Basic 6 for a programming fair that year. I called it "Crypt+". It even had C++ dll based encryption engine plugins.
The funny thing is that I got that book as a prize from a previous year's programming fair.
However, I was a kid in the seventies, when PCs were still in the future, so I had to practice cryptography with pen and paper.
While in high school, I wrote my first programs, but at that time this was done by writing the program (e.g. in FORTRAN) on a special printed form, on a grid where each character was accurately positioned, then the form was given to an operator who transferred the written program on 80-column punched cards, and then the next day you could retrieve the printed results from running your program on an IBM mainframe (printed with a 132-column line printer), together with the deck of punched cards, to be used if you wanted to rerun the program (which you almost always wanted to do, even if the program had been intended to be run only once, because your first attempt of running might have printed only compiler error messages).
There has been a long journey from that until being able to use VB6 or Visual C++.
There's a whole bunch of history books around WW2, the Enigma Machine, and surrounding historical and technical details. I can't recommend any specific one, but this might be more interesting read, with more context, than a text on crypto. It's also quite neat because it's kind of like a basic cipher taken to the extreme, setting the stage for what a revolutionary (and counter-intuitive) discovery public key encryption was.
Was one of the best books I read back in the day, It wasn't only about the algorithms themselves, also about how many verification schemes worked, in an easy to understand manner.
Today I'd say the knowledge of protocols is still valid, just that the algorithms first themselves need to be post-quantum secure.
I don't want to go off on a whole thing here given this is a thread about books for children, but this is definitely not true and hasn't been true for decades; it might never have been true. The cryptography in "Applied Cryptography" would have gotten you in pretty deep trouble as far back as the late 1990s. It's missing most of modern cryptography.
That book is too old to be useful for practical applications today, but it contains a lot of useful historical information.
It is not missing most of modern cryptography, it misses only a few, albeit very important things, like post-quantum public-key algorithms, memory-hard functions for password-based algorithms, and integrity-verification algorithms with intrinsic encryption (for the latter 2 classes of algorithms I am not aware of any modern cryptography book that includes a correct and complete presentation, despite their practical importance; the information about them is spread over a large number of research papers published during the last quarter of century, and one must search and read all those papers, to be well informed).
Most of the principles of modern cryptography have barely changed after 1980, even if the specific algorithms that implement them have greatly evolved, so that almost no algorithm older than AES is still useful.
For an introduction to the principles of modern cryptography the old book of Schneier is still fine, even if the specific algorithms are no longer useful.
There are much better books for someone who is already familiar with cryptography or with abstract algebra and wants to learn something that can be used in practice, but most of those are too dense for someone without good prior knowledge of mathematics or cryptography.
Years ago, I wrote a whole blog post about the problems with this book. Even his much better regarded followup, "Practical Cryptography", is premodern in important ways (that would get you in trouble today).
I agree with most that you have written there, and I already said that Schneier"s book is not useful for someone who wants a recipe for implementing a cryptographic system in practice.
As you have said, all the descriptions of obsolete ciphers are useless for someone who wants a practical implementation, for which AES is the right choice.
However, in this thread the discussion was about a book to introduce someone in the domain of cryptography, not to make him a professional who will immediately design a cryptographic product. For this initial learning purpose, all the descriptions of historical ciphers are useful.
No really competent cryptographer can understand what is good and what is bad in a block cipher like AES, without studying all the previous block cipher designs, especially which were their flaws, starting with IBM's Lucifer and DES, until all the candidates of the AES competition.
The best way to study cryptography is not from any books but from all the relevant patents and research papers, but to reach that level it is good to be exposed in the beginning to more accessible books, like the Schneier book, even if those may contain some things that later will require corrections.
Not even among the newer and better books have I seen anyone that does not contain a few confusions or mistakes.
While most of your objections written at that link are correct, I can find various things to nit pick.
For instance you write "We know today that you want to encrypt, then authenticate; to do otherwise is to invoke Moxie Marlinspike’s Cryptographic Doom Principle".
You make here reference to an excellent research paper, which has a well-deserved reputation, but in reality the conclusion of that paper contains additional information that you do not mention, and which invalidates your addition about the "Doom Principle".
What that paper proved is that "Encrypt-then-MAC" is what you must do when "Encrypt" and "MAC" are black-box algorithms, about which nothing is known.
On the other hand, for particular "Encrypt" and "MAC" algorithms, it is frequent that "MAC" then "Encrypt" is perfectly secure, and this was also explained in that research paper.
The reason why you may want to do "MAC-then-Encrypt" for certain specific algorithms is that in those cases it is possible to obtain a higher performance than when combining generic algorithms into "Encrypt-then-MAC". The reason why "MAC-then-Encrypt" can be faster is because in this sequence the MAC algorithm may be a weaker algorithm, and weaker algorithms can be faster.
Some of the most important AEAD algorithms (Authenticated Encryption with Associated Data) are actually built as "MAC-then-Encrypt" algorithms. They are specified as single algorithms precisely to prevent the user from combining in another way their "MAC" and "Encrypt" components, which unlike the carefully designed combination from the AEAD specification, could be insecure.
The correct recommendation about "Encrypt-then-MAC" is that, when in doubt, you should do "Encrypt-then-MAC", but when you are a cryptography expert and you know what you are doing, you should do "MAC-then-Encrypt" with correctly chosen, compatible algorithms, for maximum performance.
The "Encrypt-then-MAC" recommendation is of the same kind like the recommendation that you should use a standard validated cryptography library and you should not write your own. This is good advice for most people, but obviously it cannot be the correct advice for everybody, otherwise no standard validated cryptography libraries would exist.
In another place you criticize Schneier because he recommends to compress a file before encryption because "It turns out, no. The length of the messages in a cryptosystem is also a potential side channel".
What you say there is not a counter-argument to Schneier. First, in the case of a file, which presumably would be encrypted only once, it is very unlikely that an attacker could mount the chosen-plaintext attack that you described for compressed messages.
Even in the case when encryption is applied to communication, not to stored files, there are trivial counter-measures for hiding the length of the transmitted data, regardless if it is first compressed, or not. One can transmit only packets of the same length. If too much time passes without accumulating enough data for transmitting a whole packet, the remainder of the packet can be filled with random junk, and it can be transmitted.
So the recommendation of Schneier is valid. Frequently it is desirable to compress data before encryption. What you say about the need to avoid leaking information from data length is also correct and important, but it is a separate problem.
I'm just responding to the comment I was responding to, which made a much broader claim about Applied Cryptography than that it would be interesting and motivating to someone who wanted to learn more about cryptography. It's important that people not reach the conclusion that, but for missing PQ content, Applied Cryptography is a steady foundation on which to build practitioner knowledge. It is something much more like a missing stair for practitioners!
(At this point I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options.)
I did not remember immediately your reference about "Moxie Marlinspike’s Cryptographic Doom Principle", so I had to search it on the Internet.
That doom principle is: "When you receive a message, the very first thing you can do is verify the MAC".
What confused me was the name of Moxie Marlinspike, because this principle was not coined by him (in 2011), but it was discussed at length during the nineties of the last century, by the designers of IPsec, a decade and a half before Moxie.
This principle was the reason why IPsec chose to do "Encrypt-then-MAC", unlike SSL or SSH. The differences between IPsec, SSL and SSH in the order of encryption and MAC computation prompted Hugo Krawczyk to write in 2001 his paper "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", which clarified the properties of the 3 different orders used at that time by IPsec, SSL and SSH.
Nonetheless, this "Doom Principle" is obsolete.
30 years ago, when IPsec was designed, it was true that doing first only the MAC computation saved time for the case when decryption was no longer required (because the packet was corrupted or forged).
Nowadays, reading the encrypted data from the memory is normally the bottleneck, not the MAC or decryption computations. Therefore, one should never do 2 passes over data, one for MAC and one for decryption, but one should do a single pass, during which both MAC and decryption should be computed, regardless which is their order. Even when small packets are decrypted, so the second pass would find the data in the cache memory, doing a single pass over the data is still faster.
When a single pass over data is done, it no longer matters in which order MAC and encryption had been done, regardless whether the data passes or fails the integrity verification.
> I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options
I agree. Today, most people should use only one of the standardized authenticated encryption algorithms, like those specified by TLS 1.3 or SSH.
On most modern CPUs (which have dedicated hardware for both AES and the GCM MAC), doing something better than this cannot be achieved by any generic composition of ciphers and MACs, but it can be achieved with other authenticated encryption algorithms, which have not become widespread mostly because of the broken US IP laws (i.e. they were covered by various bogus patents).
Came here to mention this. It's not too applicable to modern/useful cryptography, but introduces a bunch of related hidden-information concepts like product date codes, which I think I actually use far more often.
should you and your kid speak french or spanish, "la bible des codes secrets" by Hervé Lehning, the bible of secret codes, is a book I greatly enjoyed as a young teen. it walks you through the history of cryptography until the current times, and has a lot of examples where you can try it out yourself. it is almost not coding-oriented, with only the last 3 chapters explaining modern-day encryption, but as far as my experience goes, few ten-year old enjoy reading documentation or textbook-style books. This one is very didactic, and also an interestin tour through history.
Не удалось войти в аккаунт
a
kockonbaevvmunarbek@gmail.com
Google не удается распознать это устройство, и нам не хватает данных, чтобы убедиться, что это вы. В целях безопасности войти в аккаунт прямо сейчас нельзя.
Попробуйте войти в аккаунт из местоположения или с устройства, где вы уже выполняли вход раньше.
For a 10 year old? The book where the main character does No Nut November in a prison cell and then "experiences relief" quite graphically with the love interest?
- _Codes & Secret Writing_ by Herbert S. Zim
- _Codes and Ciphers: Secret Writing Through the Ages_ by John Laffin
- _Codes, ciphers, and secret writing_ by Martin Gardner
There was another book on alphabets/letterforms and ciphers --- pretty sure it had a cover designed by Oscar Ogg, but blanking on the name and can't find it.
While searching online for that found:
Secret Writing: An Introduction to Cryptograms, Ciphers, and Codes by Henry Lysing and John L. Nanovic
Cryptography adjacent (it's about the difficulty of deciphering a dead language), but H. Beam Piper's novella "Omnilingual" really should be part of the grade school canon --- lightly updated version at:
https://vrici.lojban.org/~cowan/omnilingual.html
https://usborne.com/au/official-spy-s-handbook-9781409584384
P.S. In fact, I was going to send that book to my friend's son who is about same age, and who got some sudden interest in cryptography recently. So it is safe to say that I am now aware of at least two 10 year olds who have interest in Cryptography. I feel a bit surprised, but in a good way :)
He started with inventing his own alphabet and language as he was learning to read and write, which eventually evolved into reinventing the Secret Decoder Ring with increasing complexity, so we want to encourage him in his adventure.
In high school, we had to pick a math book to do a book report on. There were lots of people picking books like Flatland, but I ended up with "In Code". I actually thought it was a programming book because of the word "code" in the title. Turns out I was wrong, and I got exposed to learning cryptography as a high schooler! And since it was a book report, my reading culminated with me fumbling through explaining public key cryptography to my math class.
One angle from which it's fun is just learning operations you can do on text (and text represented as numbers). Empirically it turns out just Shannon's "diffusion and confusion" and lots of rounds gets you far in symmetric cryptography, which we can see from a lot of simple RAX primitives working fine. But it's nice for reasons outside cryptography to get a feel for the zoo of other things you can do, what offers diffusion and nonlinearity, how you can ensure a function's reversible, etc.
If you did one topic from public-key land, I think Diffie-Hellman is easier to understand than RSA without much build-up: it makes sense from the basic properties of exponents (ones modular arithmetic doesn't change), and modular arithmetic connects to fun stuff about the primes. Merkle hash signatures also make sense with just symmetric cryptography, and are post-quantum-resistant!
I hadn't really thought about how you'd even approach PQ encryption, but maybe ECC-based McEliece is cool? You can get a feel for it even without detail on the hard decoding problem, and error correcting codes are their own interesting topic.
https://web.archive.org/web/20100128072801/http://www.nsa.go...
(They went offline a few administrations ago, hence the archive link)
You can also jump around the timeline in the archive to see different versions.
Once he's getting some diminishing returns, I recommend Computer Science Unplugged: https://classic.csunplugged.org/documents/books/english/CSUn...
It teaches the basics of information theory and computability with a series of lessons and paper games (including some ciphers and why they work). All of my kids went through it, and had fun doing it.
Mine are out of the house, but I had a few who might have really liked doing something like this.. could make a nice Christmas present, the first mysterious letter..
"I think most children can grasp difficult material if an adult that's good at the meta-skill of teaching is helping them with it via individual attention" That's how we feel too and they appreciate being given that chance if we don't push.
The Code Book by Simon Singh
The Codebreakers by David Kahn
The Mathematics of Secrets by Joshua Holden
It does assume a fair bit of historical context knowledge, though, much of which probably exceeds 5th grade. Probably 9th graders would have it easier as far as, e.g., familiarity with WWII, etc.
It’s a slim volume that focuses on historical and fictional ciphers. It stars with simple shift ciphers like Caesar’s cipher, progresses to more complex substitution ciphers with examples from Sherlock Holmes and Edgar Allen Poe, then covers polyalphabetic ciphers like Vigenère and Playfair. It covers basic cryptanalysis and has practice riddles and cryptograms throughout. It even has a chapter on a variety of ways to make invisible ink, which is often an object of fascination for children around that age!
The Giant Raft or 800 Leagues On The Amazon
Mathias Sandorf
A Journey To The Centre of the Earth
After reading those, I played with the ciphers described there, i.e. I made and used the transposition grid from Mathias Sandorf and I used various Vigenère ciphers, like that from "800 Leagues On The Amazon".
Due to the interest generated by those stories, a few years later I read various textbooks about modern cryptography.
The book "Applied Cryptography" by Bruce Schneier is now somewhat old, so it is no longer up-to-date, but it is written in a style more accessible for newbies than most textbooks about cryptography, so I think that it would be adequate for a teenager who is good at mathematics.
The funny thing is that I got that book as a prize from a previous year's programming fair.
However, I was a kid in the seventies, when PCs were still in the future, so I had to practice cryptography with pen and paper.
While in high school, I wrote my first programs, but at that time this was done by writing the program (e.g. in FORTRAN) on a special printed form, on a grid where each character was accurately positioned, then the form was given to an operator who transferred the written program on 80-column punched cards, and then the next day you could retrieve the printed results from running your program on an IBM mainframe (printed with a 132-column line printer), together with the deck of punched cards, to be used if you wanted to rerun the program (which you almost always wanted to do, even if the program had been intended to be run only once, because your first attempt of running might have printed only compiler error messages).
There has been a long journey from that until being able to use VB6 or Visual C++.
(used copies still available)
Was one of the best books I read back in the day, It wasn't only about the algorithms themselves, also about how many verification schemes worked, in an easy to understand manner.
Today I'd say the knowledge of protocols is still valid, just that the algorithms first themselves need to be post-quantum secure.
It is not missing most of modern cryptography, it misses only a few, albeit very important things, like post-quantum public-key algorithms, memory-hard functions for password-based algorithms, and integrity-verification algorithms with intrinsic encryption (for the latter 2 classes of algorithms I am not aware of any modern cryptography book that includes a correct and complete presentation, despite their practical importance; the information about them is spread over a large number of research papers published during the last quarter of century, and one must search and read all those papers, to be well informed).
Most of the principles of modern cryptography have barely changed after 1980, even if the specific algorithms that implement them have greatly evolved, so that almost no algorithm older than AES is still useful.
For an introduction to the principles of modern cryptography the old book of Schneier is still fine, even if the specific algorithms are no longer useful.
There are much better books for someone who is already familiar with cryptography or with abstract algebra and wants to learn something that can be used in practice, but most of those are too dense for someone without good prior knowledge of mathematics or cryptography.
https://sockpuppet.org/blog/2013/07/22/applied-practical-cry...
As you have said, all the descriptions of obsolete ciphers are useless for someone who wants a practical implementation, for which AES is the right choice.
However, in this thread the discussion was about a book to introduce someone in the domain of cryptography, not to make him a professional who will immediately design a cryptographic product. For this initial learning purpose, all the descriptions of historical ciphers are useful.
No really competent cryptographer can understand what is good and what is bad in a block cipher like AES, without studying all the previous block cipher designs, especially which were their flaws, starting with IBM's Lucifer and DES, until all the candidates of the AES competition.
The best way to study cryptography is not from any books but from all the relevant patents and research papers, but to reach that level it is good to be exposed in the beginning to more accessible books, like the Schneier book, even if those may contain some things that later will require corrections.
Not even among the newer and better books have I seen anyone that does not contain a few confusions or mistakes.
While most of your objections written at that link are correct, I can find various things to nit pick.
For instance you write "We know today that you want to encrypt, then authenticate; to do otherwise is to invoke Moxie Marlinspike’s Cryptographic Doom Principle".
You make here reference to an excellent research paper, which has a well-deserved reputation, but in reality the conclusion of that paper contains additional information that you do not mention, and which invalidates your addition about the "Doom Principle".
What that paper proved is that "Encrypt-then-MAC" is what you must do when "Encrypt" and "MAC" are black-box algorithms, about which nothing is known.
On the other hand, for particular "Encrypt" and "MAC" algorithms, it is frequent that "MAC" then "Encrypt" is perfectly secure, and this was also explained in that research paper.
The reason why you may want to do "MAC-then-Encrypt" for certain specific algorithms is that in those cases it is possible to obtain a higher performance than when combining generic algorithms into "Encrypt-then-MAC". The reason why "MAC-then-Encrypt" can be faster is because in this sequence the MAC algorithm may be a weaker algorithm, and weaker algorithms can be faster.
Some of the most important AEAD algorithms (Authenticated Encryption with Associated Data) are actually built as "MAC-then-Encrypt" algorithms. They are specified as single algorithms precisely to prevent the user from combining in another way their "MAC" and "Encrypt" components, which unlike the carefully designed combination from the AEAD specification, could be insecure.
The correct recommendation about "Encrypt-then-MAC" is that, when in doubt, you should do "Encrypt-then-MAC", but when you are a cryptography expert and you know what you are doing, you should do "MAC-then-Encrypt" with correctly chosen, compatible algorithms, for maximum performance.
The "Encrypt-then-MAC" recommendation is of the same kind like the recommendation that you should use a standard validated cryptography library and you should not write your own. This is good advice for most people, but obviously it cannot be the correct advice for everybody, otherwise no standard validated cryptography libraries would exist.
In another place you criticize Schneier because he recommends to compress a file before encryption because "It turns out, no. The length of the messages in a cryptosystem is also a potential side channel".
What you say there is not a counter-argument to Schneier. First, in the case of a file, which presumably would be encrypted only once, it is very unlikely that an attacker could mount the chosen-plaintext attack that you described for compressed messages.
Even in the case when encryption is applied to communication, not to stored files, there are trivial counter-measures for hiding the length of the transmitted data, regardless if it is first compressed, or not. One can transmit only packets of the same length. If too much time passes without accumulating enough data for transmitting a whole packet, the remainder of the packet can be filled with random junk, and it can be transmitted.
So the recommendation of Schneier is valid. Frequently it is desirable to compress data before encryption. What you say about the need to avoid leaking information from data length is also correct and important, but it is a separate problem.
(At this point I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options.)
That doom principle is: "When you receive a message, the very first thing you can do is verify the MAC".
What confused me was the name of Moxie Marlinspike, because this principle was not coined by him (in 2011), but it was discussed at length during the nineties of the last century, by the designers of IPsec, a decade and a half before Moxie.
This principle was the reason why IPsec chose to do "Encrypt-then-MAC", unlike SSL or SSH. The differences between IPsec, SSL and SSH in the order of encryption and MAC computation prompted Hugo Krawczyk to write in 2001 his paper "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", which clarified the properties of the 3 different orders used at that time by IPsec, SSL and SSH.
Nonetheless, this "Doom Principle" is obsolete.
30 years ago, when IPsec was designed, it was true that doing first only the MAC computation saved time for the case when decryption was no longer required (because the packet was corrupted or forged).
Nowadays, reading the encrypted data from the memory is normally the bottleneck, not the MAC or decryption computations. Therefore, one should never do 2 passes over data, one for MAC and one for decryption, but one should do a single pass, during which both MAC and decryption should be computed, regardless which is their order. Even when small packets are decrypted, so the second pass would find the data in the cache memory, doing a single pass over the data is still faster.
When a single pass over data is done, it no longer matters in which order MAC and encryption had been done, regardless whether the data passes or fails the integrity verification.
> I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options
I agree. Today, most people should use only one of the standardized authenticated encryption algorithms, like those specified by TLS 1.3 or SSH.
On most modern CPUs (which have dedicated hardware for both AES and the GCM MAC), doing something better than this cannot be achieved by any generic composition of ciphers and MACs, but it can be achieved with other authenticated encryption algorithms, which have not become widespread mostly because of the broken US IP laws (i.e. they were covered by various bogus patents).
In the same vein, is the "The Adventure of the Dancing Men" [1]
[1] https://en.wikipedia.org/wiki/The_Adventure_of_the_Dancing_M...
ISBN-10 : 1681195143 ISBN-13 : 978-1681195148
Title: Top Secret: A Handbook of Codes, Ciphers and Secret Writing
ISBN-10 : 0763629723 ISBN-13 : 978-0763629724
[0]: https://sherlock-holm.es/stories/pdf/letter/1-sided/danc.pdf
https://www.amazon.com/Cryptanalysis-Study-Ciphers-Their-Sol...
Helen Gaines Cryptanalysis: A Study of Ciphers and Their Solution
https://unspent.cash/bitcoin.jpg
https://www.amazon.com/dp/1138413151
[1]: https://nostarch.com/mangacrypto
U WJZI VH KZJBY QYIM HUZFGBZ.
Key: TRENCH
Something like that would be practical.