For those of you who don't know what the acronyms stand for, I've compiled a list, in order by their appearance:<p><pre><code> AES - Advanced Encryption Standard
CBC - Cipher Block Chaining
PKCS - Public Key Cryptography Standards
SHA - Secure Hashing Algorithm
MAC - Message Authentication Code
PBKDF - Password-Based Key Derivation Function
NIST - National Institute of Standards and Technology
FIPS - Federal Information Processing Standard
KDF - Key derivation function
CTR - Counter Mode
RSA - Rivest Shamir Adleman (last names of each creator of the RSA algorithm)
OAEP - Optimal Asymmetric Encryption Padding
PSS - Probabilistic Signature Scheme
ECDSA - Elliptic Curve Digital Signature Algorithm
PS3 - Playstation 3?
DH - Diffie-Hellman key exchange
ECDH - Elliptic curve Diffie-Hellman key exchange
TLS - Transport Layer Security</code></pre>
I happen to know the author of this. This was a really tough thing for him to read, but he's taking it as constructive criticism.<p>I would add to the people commentating here on HN: tptacek's review is tough; you do not need to lay into the author of this book any more.
If I had written a book on implementing cryptography in Golang, I assure you that someone else would have reviewed it harshly too. It's simply a difficult subject to get right.
From tptacek's comment, it sounds like the author of the book may just be an inexperienced practitioner of cryptography who's only crime is to be too eager to spread what they've learned.<p>Someone who picked up the basics from a few Wikipedia articles here, a few papers there, a couple open source projects here and there... they're smart, so they're not completely clueless about the field, but they just don't have the experience to see where they fall short, the industry know-how, and so on.<p>I feel like instances of this in the tech community are not too rare, and it's a consequence of the internet: anyone can publish a book and distribute it all over the world now. It's worth keeping in mind that while harm is being done through the spread of false information, what's most important is to educate them, see this as a teachable moment, so they can become productive experts and modify their message to be fully correct. Of course, it requires them to be open minded of their shortcomings: but it can be done.<p>PS: I have no clue who the author of Practical Cryptography With Go is.
I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine. In all cases you have a system whose failure can result in anything from monetary loss to death (for an example of the latter, faulty cryptographic software used by dissidents in repressive countries). In all cases you use a combination of rigorous testing and analysis from first principles to try and isolate potential weaknesses. In all cases you want to ensure the people who worked on the system knew what they were doing and put the right amount of due diligence into ensuring the system works correctly.<p>Unfortunately, not even widely used, highly trusted implementations work right all the time. A out-of-bounds memory bug introduced by an insufficiently vetted commit opened up a serious flaw in OpenSSL. On a much, much smaller scale, I once had the misfortune of working with an old version of Microchip's PIC18 AES library, which had some serious issues that made it nonfunctional for anything more complex than the toy sample app it shipped with. But with enough exposure these problems are eventually exposed and fixed. Would a world where everyone rolled their own bespoke, ad-hoc SSL implementations be more secure? I doubt it.<p>In the end, I think there needs to be a cultural shift. People shouldn't be discouraged from building their own crypto for fun and learning, but they should be discouraged from deploying it for any application where real security is required - at least not before undergoing rigorous analysis. One of the first things Dan Boneh teaches in his Crypto I class is that you should think very long and hard before implementing your own cryptosystems (i.e. don't do it), because getting it right is hard, and getting it even the slightest bit wrong tends to make it useless. And when you consider that people's livelihoods (their personal information, their money) and even lives might be jeopardized, taking responsibility as an engineer becomes of paramount importance. Crypto just doesn't lend itself to a "build an MVP, get it working, move fast and break things" mindset.
tptacek makes a number of good points but I find it hard to agree with this one:<p>> there is concern that the NIST curves are backdoored and should be disfavored and replaced with Curve25519 and curves of similar construction.<p>Of course, "there is concern" is pretty vague, but it should be made clear that such concerns are in the realm of pure speculation at this point. There is simply no known way of constructing a "backdoored" elliptic curve of prime order over a prime field (in particular, the closest thing resembling such a backdoor, namely Teske's key escrow technique based on isogenies from GHS-weak curves, cannot work over a prime field). Scientifically speaking, I don't see more reasons to believe the assertion that "NIST parameters are backdoored because they aren't rigid" than the (equally unfounded) speculation that "Curve25519 may be weak because it has small parameters/a special base field/composite order/etc.".<p>Moreover, to say that the NSA has backdoored the NIST curve parameters is to assume that they have known, for quite a long time now, a serious weakness affecting a significant fraction of all elliptic curves of prime order over a given base field that has so far escaped the scrutiny of all mathematicians and cryptographers not working for a TLA. Being leaps and bounds ahead of the academic community in an advanced, pure mathematical subject doesn't quite align with what we know about NSA capabilities.<p>Don't take this the wrong way: there <i>are</i> good reasons to favor Curve25519 and other implementation-friendly elliptic curves (namely, they are faster, and they are fewer ways of shooting yourself in the foot if you implement them), but "NIST curves are backdoored" is not a very serious one.
Brutal but also in some ways a gift to the author/publisher. Paired with the 1st edition, it cures the major defects.<p>And, if the criticisms can be addressed, in both specifics and perspective, for a future edition, they'll have a hardened book... almost sure to earn another updated expert review ("is it fixed?") at that time.
Can someone explain me this?<p>> In considering RSA, the book recommends /dev/random, despite having previously advised readers to avoid /dev/random in favor of /dev/urandom. The book was right the first time.<p>From "man 4 urandom":<p>> A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.<p>In fact, using /dev/urandom is one of the causes of the creation of weak ssh key, found in this research: <a href="https://factorable.net/" rel="nofollow">https://factorable.net/</a><p>So: Why is /dev/urandom the correct choice over /dev/random ?
After I finished reading this review, I came to check out the HN comments knowing that the tone would be the subject of the top comments.<p>When did this community become more concerned with tone than correctness? The top of this thread is <i>filled</i> with people saying that the tone is bad, it's unproductive, it's unnecessary, etc. Yet nobody seems concerned about the published book filled with bad information that a lot of people are going to "learn" from. What gives?
I'll take it on faith that Thomas really wrote this (it's his style), but would the real Thomas 'H' Ptacek please acknowledge that he indeed wrote this (it is labeled 'anonymous').
This is a good illustration of how, 1) crypto is hard 2) real-world cryptosystem design & implementation is hard and 3) teaching the aforementioned is hard.<p>I read Schneier's & Ferguson's Practical Cryptography years ago, the only thing I remember about it is the "don't try this at home" message.
> The book <i>actively recommends</i> public key cryptography, because of concerns about key distribution. Again: bad strategy. Cryptographers use public key crypto only when absolutely required. Most settings for cryptography don't need it! Public key cryptography multiplies the number of things that can go wrong with your cryptosystem.<p>Can I ask why? What is so dangerous with asymmetric crypto compared to symmetric crypto?
Does Tptacek have a list of books/articles he would recommend to the Crypto neophyte? I'm talking about books which could be considered de facto standards like Knuth's TAOCP or Steven's TCP/IP books.
can someone explain this?<p><pre><code> * This book, I am not making this up, contains the string: "“We can use ASN.1 to make the format easier to parse".
</code></pre>
Last time I had something to do with ASN.1 was years ago but it seemed to work well, libraries were full featured and cross-language interop was ok. What am I missing that makes ASN.1 bad ?<p>Or is the critique to an attempt to write a custom ASN.1 serializer/parser?
The last paragraph of this review is in poor taste. The most cursory research into the author's "CryptoBox" shows that indeed this project is <i>inspired</i> by NaCL.
This is a great review for two reasons:<p>a) it provides readers with a laundry list of things to go study independently<p>b) the book author can, given time and inclination, do the same study and improve the book
As someone finishing the final edits of a technical book (on Golang, at that) this is the kind of thing that horrifies me.<p>I want to go through every single chapter and rewrite it to stave off the imaginary critics in my head who will undoubtedly tear it apart.
Those with glass ceilings shouldn't throw stones<p>While criticism is good, the condescending way it is presented, as well as being overly critical are bad. Example:<p>"Total undue reverence for NIST and FIPS standards; for instance, the book recommends PBKDF2 over bcrypt and scrypt (amusingly: the book actually recommends <i>against</i> scrypt, which is too new for it) because it's standardized."<p>I know people love scrypt and bcrypt, and have been proven safe <i>so far</i>, but there are advantages to use standardized methods. An implementation can make something less safe than the standard.
Reading this makes me think that the Go crypto primitives could use a lot more plumbing; it would make them more useful, and avoid some pitfalls by making it easier to do the right thing.
I wonder who the intended audience of this review is. The book is clearly geared toward beginners. It would seem a review of such a book should be geared toward those who might read it to learn about cryptography. This review is obviously geared toward some other audience, however. Otherwise a criticism like
<i>The book writes its own Diffie-Hellman implementation and recommends it to readers</i>
would be backed up and explained, instead of being expected to stand on its own.<p>Is the audience for this review intended to be cryptography experts, who would not read such a book except to praise or trash it? If that's the case, it seems rather mean spirited. More "wow check this loser out" than "I don't recommend this book to beginners or anyone and here's why."