Practical Cryptography for Developers | Hacker News Reader

Practical Cryptography for Developers

cryptobook.nakov.com

96 pointsBerislavLopac10 comments

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?

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.

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.

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.

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.

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.

Without offering any other commentary on this book, I'd recommend not using the Python libraries it uses for examples, and instead using pyca/cryptography.

Thank you everyone for the comments about this very early draft of my book. Thank you for reporting these technical bugs. It is important to fix them before the official release. I would be highly misleading for the readers to publish inaccurate information.

I am not sure how this early draft has leaked from my GitHub. Maybe I need to move it to private repo + password-protected Web site, until I finish this work. I am sorry that this unfinished early draft has reached you. I will announce the book in my blog when it is officially published and available in Amazon. It is too early now.

I plan to proof read the book to fix the obvious mechanical mistakes (like the mentioned above), to have an English language editor, technical editor and to fix all bugs reported in the GitHub issue tracker.