[ninegunpi]

Opened the book, read first random page (https://cryptobook.nakov.com/key-exchange/diffie-hellman-key...), closed the book.

If this is what "developers need to know", then explaining why anonymous key exchange is susceptible to MiTM and what can we do about it (PKI/CA/prior key exchange) would be way more useful than providing background of how DHKE actually works (there are way better explanations than repeating copybook examples anyway).

Upd: out of sheer curiosity, opened second page. https://cryptobook.nakov.com/symmetric-key-ciphers/cipher-bl.... Can we at least teach developers about nonce/IV challenges in GCM before saying it's "is highly recommended in the general case"? Perhaps, spending some page length on encrypt-then-sign, sign-then-encrypt and sign-encrypt-MAC merits would be more helpful to developers than CTR block scheme?

[thr0w__4w4y]

Sigh. Yep, I also ran into trouble on my first jump in a few pages from the start:

> "asymmetric encryption uses a public-key cryptosystem (like RSA or ECC) and a key-pair: private key (encryption key) and corresponding public key (decryption key)"

Ummm.... when using RSA to encrypt something (e.g., a DEK) you use the other party's public key, and of course the other party uses its private key to decrypt.

How do you get stuff like this so wrong??? Sheesh, even flipping a coin gives you a 50-50 chance.

[mclehman]

Sections like this too:

>DHKE was one of the first public-key protocols, which allows two parties to exchange data securely, so that is someone sniffs the communication between the parties, the information exchanged can be revealed.

I don't think that information being revealed through passive observation is a selling point of DHKE.

[celticninja]

The point they are trying to make is that you can sniff the exchanged information during key setup, but knowing this does nothing for the attacker. That information is not required to be secret. So " the information exchanged can be revealed." means 'it can be revealed without concern for security of the key generated by the process'. The author doesnt mean that the eventual messages will be revealed.

[masterfooo]

it would be nice if you lay your case in under a more positive attitude. You just checked only two pages so far. I am not the author btw.

[ninegunpi]

You are correct. I get a bit irritated when somebody claims to teach developers "all they need to know about cryptography" and goes on with explaining things they'd be happy to obsess on, instead of explaining things they _need to know_ to use cryptography securely.

These two pages themselves are important enough, these omissions are bad enough to disqualify any other effort in this book - cryptography is a tightly-knit system and making one or two mistakes simply nullifies the effect of making hundreds of correct decisions.

There are books on the subject which get it right, this is not the one.

It's like teaching people chinese gymnastics and saying it will protect you on the street - sooner or later someone has to punch you in the face for that.