Why I’m Writing a Book on Cryptography
cryptologie.net
cryptologie.net
I like your diagrams (I used sequence diagrams as a way to visualize BAN logic for protocols in my own stuff), and they will really elevate the discussion.
Why use an HMAC instead of a KMAC? Why would anyone want to derive a key? When does it matter whether you use an integer or Galois field counter? Why bother calling it a GF when it's just binary anyway? Why would I chose a protocol that used a symmetric cipher over an asymmetric one? When I was working on (and breaking) tokenization protocols, the discussions I was in started with getting developer agreement on why we needed to use a given primitive, and then asking how/whether each implementation decision supported that need. It's the old "start with why" method of explaining.
Ordinarily I wouldn't be so free with opinions on someones work, but systems designed to frustrate humans ability to comprehend them, shockingly, are among the most difficult subjects to write about. So looking forward to a copy, as admittedly I still find some more modern concepts a bit mystifying.
This one took me a while until we needed it for an IOT widget.
Asymmetric keys are real CPU-heavy and most market crypto will instead use symmetric keys, then send some asymmetric keys down the pipe.
> Why use an HMAC instead of a KMAC?
First, SHA-3 (and thus KMAC) isn't particularly performant without hardware acceleration, and hardware acceleration (ASICs/special CPU instructions) isn't really available yet. So if you're not on an FPGA, KMAC will be slow. Second, SHA-3 isn't available as a builtin in most libraries, so it requires another import. Third, Blake2/Blake3 are faster in software and support similar MAC modes. So until hardware comes out with SHA-3 intrinsics that's a nicer alternative to HMAC.
> Why would anyone want to derive a key?
Lots of reasons! You might need to derive a fixed-size key from a passphrase. This requires a password-based KDF, like Argon2 or scrypt. You might need to derive a key from a field element like the result of a Diffie-Hellman exchange. The raw result isn't generally suitable for use as a key, since it's not likely the right size and might be biased. You might need to derive a sequence of keys from an initial value, say to provide forward secrecy like Signal's double ratchet algorithm.
> When does it matter whether you use an integer or Galois field counter? Why bother calling it a GF when it's just binary anyway?
These two questions are related. Fields are used because they satisfy certain mathematical properties that the integers don't. Galois fields are used because they don't require floating-point or rational values, everything within them is an integer (of some special representation). We call it a GF element instead of an integer because it's not just binary any more than a .jpg image is just binary. It's representing something specific, and the usual arithmetic operations are implemented differently for elements of a field than they are in general. Many systems store the (binary) coefficients of rather high degree polynomials in the bits of an integer, and then add & multiply polynomials. The results will be different than if you added or multiplied the relevant integers, the operations share a name but are not identical. Others use things like elliptic curve points (with an X & Y coordinate), which clearly aren't integers even if both coordinates are.
> Why would I chose a protocol that used a symmetric cipher over an asymmetric one?
Symmetric ciphers are much, much faster. Symmetric keys are much smaller. Symmetric ciphers tend to be far easier to implement safely, and far more resistant to cryptanalitic attack. They're generally just safer.
e.g. We need to prove to a counterparty that some data has not been tampered with, we're limited to the processing power of the IC on a smart card, and the whole protocol can't take more than a couple of seconds including network latency. Do we just self-assert the integrity of the message using an HMAC, or do we need to prove the data hasn't been replayed or injected? In the latter case, we might need an additional key/secret to verify that transaction integrity as well, implying KMAC.
The part about counters gets weird, because it's unclear (to me) in some implementations whether the GF counter is supposed to act as an additional secret/diversification component with enough entropy to be a secret, implying that the function that generates it is also a cryptographic function, with a seed, which becomes in effect just another key to manage.
Of course this could be a misunderstanding on my part as well, and without a BAN protocol diagram, it's hard to reason about. Some of the stuff I worked on, the designers basically kept nesting key management problems until people stopped listening. I've posted this a few times I think, but I share it with everyone, as it's a great reference for how these things are designed. http://www.lsv.fr/Software/spore/index.html
cartCount 1
cart
0
id 1157
productOfferingId 2073
title "Real-World Cryptography"
edition "MEAP"
sku "wong-combo"
variant "combo"
category "Data,General"
brand "book"
quantity 1
cost "29.99"
desc "Real-World Cryptography (print book edition)"
image "https://images.manning.com/book/d/dbc9f54-a6a1-4551-bcce-942e2e7894fa/Wong-RWC-MEAP-HI.png"
url "https://www.manning.com/books/real-world-cryptography"
Genuinely not sure what to do next ...
Edit
OK, clicked on the "cart" button, and it's there, so I go through the process to check-out. The field for "State/Province" won't let me put more than three characters, and my "Province" has 6 characters.
When filling in the CC details it asks for "State", and offers only US States, even though it knows it's shipping to the UK.
Edit 2:
And I won't begin to describe the frustration in trying to create a login ... three attempts, rejecting a password that I'd copy/pasted so I know it was right. An exercise in pure frustration.
The site looks fabulous ... very glossy. My experience in using it has been unremmittingly horrible.
I can feel this. I studied cryptography at University. There was a lot of great things studied, but the first several weeks were a discussion Enigma, the war, and a life story of Alan Turing. Throw in a lesson about ancient Rome and the use of a Ceasar cipher and I was pretty bored of the course before we did any real work.
I'll be buying this book.
With a university degree in this you should be better than that. You should be curious about the history of your field and learn the context. Everybody who is not signals to me that they actually just want to hack something without a deep understanding, and then move on.
I guess people are different. For me the more background, anecdotes and stories the better when learning any field.
>This was going to be a book with little history, but filled with modern stories about cryptographic failures that I had witnessed for real.
>This was going to be a book with little about legacy algorithms, but filled with cryptography that I've personally seen being used at scale: TLS, the Noise protocol framework, Wireguard, the Signal protocol, cryptocurrencies, HSMs, threshold cryptography, and so on.
>This was going to be a book with little theoretical cryptography, but filled with what could become relevant: password-authentication key exchanges, zero-knowledge proofs, post-quantum cryptography, and so on.
Just the kind of book that appeals to me. Writing books is often a hard thankless job, thanks to the author for doing this. Planning on checking out the early preview and the final version when it is released.
Demonstrate state-of-the-art approach for a simple task of:
- making a program to encrypt or decrypt the file, given a password.
- implement that in small number of lines of code of C, so that it can be easy to verify the implementation completely (down to the possibility to inspect the binary code, if needed -- one doesn't have to trust the compiler!).
- discuss which kinds of attacks are all avoided in the implementation.
- discuss how the test could be made to detect any known state-of-the-art failures in the implementation.
Seems simple?
There are these old books talking about the modes that aren't state-of-the-art for many many years. But I am not aware of any other source directly covering all the goals.
Is there some book that covers all this? If not how about a few chapters about this too? IMHO that should be really basic.
https://www.paulkocher.com/doc/DifferentialPowerAnalysis.pdf
> I remember advising the student to read the book from Boneh & Shoup and Cryptography I from Boneh on Coursera.
> The student told me “Ah, I tried, it’s too theoretical!”. This answer stayed with me.
I tried this course and enjoyed it quite a lot, although I hadn't finished it for unrelated reasons. What I remember is that there is no math there outside of what they teach you in school. A developer that can't comprehend that little math is probably better of just using some ready-made solution, because likely no amount of diagrams will help with understanding. And if not, better not to try to roll out own crypto, even in the sense of plumbing existing primitives together.
I’m also surprised he (David Wong) doesn’t mention his surname, given his very public profile.
Reference: http://zodiackillerciphers.com/wiki/index.php?title=File:340...
lol. truer words have never been spoken. my introduction to openssl, i mean after trying to make sense of it on my own, was a website still up today, “flingpoo!”. hard to believe so much of the internet depends on this library.