
Why I’m Writing a Book on Cryptography - gedigi
https://www.cryptologie.net/article/504/why-im-writing-a-book-on-cryptography/
======
motohagiography
So looking forward to buying a copy of this! As a writer with a bit of an
atrophied crypto background, going through the online text, being able to
start with _why_ we need a hash function does a lot to tease out what they are
and how they work. Leading with how we need to be able to prove some data has
not been altered or tampered with, because reasons - may seem trite, but when
we get deeper into how you do that, being able to link it back to that reason
helps the reader develop and ontology of the concepts.

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.

~~~
SAI_Peregrinus
Just for the hell of it...

> 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.

~~~
motohagiography
Mostly agree! If I were explaining these concepts to someone, I would lead
with your answers, setting them up as problems where the thing I wanted to
explain was the solution.

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](http://www.lsv.fr/Software/spore/index.html)

------
ColinWright
Just tried to buy it. Clicked on "Add to cart", and got this:

    
    
        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"
    

Yup. Raw JSON.

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.

------
technion
> In particular, the long introductions that would start with history.

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.

~~~
oefrha
To anyone with a strong math background and not particularly interested in the
history: maybe try Stanford’s Intro to Cryptography by Dan Boneh? I took it
way back when I was an undergrad there studying math and physics, and IIRC it
got into the math very quickly (not that I didn’t enjoy the historical context
personally). It’s been available as a highly-rated MOOC for a while:
[https://www.coursera.org/learn/crypto](https://www.coursera.org/learn/crypto)

------
RcouF1uZ4gsC
>This was going to be a book with very little formulas, but filled with many
diagrams.

>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.

------
acqq
How about:

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.

------
cryptopathe
"For a class, I had to implement a differential power analysis attack, a
breakthrough in cryptanalysis as it was the first side-channel attack to be
published." <\-- Nope. The first published side-channel attack is, to the best
of my knowledge, Paul Kocher's "Timing Attacks on Implementations of Diffie-
Hellman, RSA, DSS, and Other Systems." (CRYPTO 1996). Approximately at the
same time, the Bellcore attack (fault attacks) was made public and presented
at Eurocrypt 1997. DPA was only published at CRYPTO 1999.

~~~
mratsim
Did you see that "differential power analysis attack" was underlined with a
link to Paul Kocher paper?

[https://www.paulkocher.com/doc/DifferentialPowerAnalysis.pdf](https://www.paulkocher.com/doc/DifferentialPowerAnalysis.pdf)

------
demosito666
From the article:

> 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.

~~~
NohatCoder
There is no such thing as ready-made solutions in cryptography. There are
libraries, but without a strong understanding of the problem domain people
will invariably use them wrong.

------
gorgoiler
Wow, what a resume. I haven’t heard of this person before, and it makes me
wonder what I’ve missed about Facebook’s Libra when someone like this is
working on it.

I’m also surprised he (David Wong) doesn’t mention his surname, given his very
public profile.

~~~
new2628
You probably didn't miss anything -- smart people working on questionable
projects has a long history.

------
e79
When I’m studying cryptography and mathematics, I find myself thinking
visually and scribbling down little diagrams too. The ADEPT method [0] would
suggest that this is one way to better absorb knowledge and form
understanding. It’s really cool to see more content creators exploring visual
communication.

[0]: [https://betterexplained.com/articles/adept-
method/](https://betterexplained.com/articles/adept-method/)

------
mahemm
Can't do crypto without visualizations; I can't say how many times I've wanted
someone to draw stuff out! Great article

------
catsarebetter
This is a vastly underrepresented topic in software but so necessary for the
future, looking forward to reading it

------
sriram_malhar
I am throwing money at the screen and nothing is happening!

------
edoceo
Wow, with these creds and experience. I'm ready to buy now - shut up and take
my money.

------
jonthepirate
Can you comment on the unsolved zodiac 340 cipher? I'd be willing to try to
crack it with time and effort but I'm not sure where to start.

Reference:
[http://zodiackillerciphers.com/wiki/index.php?title=File:340...](http://zodiackillerciphers.com/wiki/index.php?title=File:340-cipher-
hi-resolution.jpg)

------
mister_hn
I've bought the MEAP when it was announced, I'm waiting patiently for the
printed version!

------
techslave
> OpenSSL [...] What a clusterfuck of a library

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.

------
badrabbit
For me, a good "for dummies" reference of the symbols used in crypto would
help as much as diagrams.

~~~
NohatCoder
It is easy. The + symbol doesn't mean plus (except when it does), and that is
how it is all the way through.

------
ScottGuthart
I found the reasons to be... cryptic.

------
torgian
Take my money.

