
Practical Cryptography for Developers - BerislavLopac
https://cryptobook.nakov.com/
======
ninegunpi
Opened the book, read first random page ([https://cryptobook.nakov.com/key-
exchange/diffie-hellman-key...](https://cryptobook.nakov.com/key-
exchange/diffie-hellman-key-exchange.html)), 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...](https://cryptobook.nakov.com/symmetric-key-ciphers/cipher-block-
modes.html). 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.

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

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

Thank you again for your time to report the bugs. I will definitely fix them.

\-- Nakov

------
gluejar
added cover, generated ebook files -
[https://unglue.it/work/378964/](https://unglue.it/work/378964/)

~~~
masterfooo
thanks

