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!
77 comments
[ 0.30 ms ] story [ 45.3 ms ] threadP.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.
Something like that would be practical.
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.
ISBN-10 : 1681195143 ISBN-13 : 978-1681195148
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..
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.
"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.
[1]: https://nostarch.com/mangacrypto
(used copies still available)
U WJZI VH KZJBY QYIM HUZFGBZ.
Key: TRENCH
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 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 punched cards, and then the next day you could retrieve the printed results from running your program on an IBM mainframe, 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).
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 memory-hard functions for password-based algorithms, post-quantum public-key algorithms and integrity-verification algorithms with intrinsic encryption (for the latter I am not aware of any modern cryptography book that includes a correct and complete presentation).
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.
(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.
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 was writing about EtM constructions before Moxie wrote that post (you can see me preening about Bellare and Namprempre in Twitter search), but Moxie's post is the one everyone remembers, so that's the reference. What's "obsolete" about the advice now is that nobody builds cryptosystems by manually gluing a block cipher mode to a MAC anymore. But in the 5 years prior to that post, violations of the "principle" were the most reliable way to break cryptosystems.
Nobody's arguing that cryptographers can't design hermetically sealed authenticated encryption modes that play with the ordering of encryption and authentication. That wasn't what Moxie was implying either.
https://www.amazon.com/Cryptanalysis-Study-Ciphers-Their-Sol...
Helen Gaines Cryptanalysis: A Study of Ciphers and Their Solution