DISCLAIMER: i know and have worked with kyle (the author).
while the factual content of tptacek's review may be spot on, his overall tone is very negative and smacks of "only experts allowed" logic. while he could have easily helped improve kyle's book and shared these comments privately, he instead chose to lambast kyle publicly, which doesn't really help anybody: tptacek looks like a total jerk and kyle now has a lot of negative attention on (this version of) his book.
this pervasive "experts only" attitude is a big part of why "secure" open source projects have hard times getting and keeping contributors. it is par for the course for people to be super rude and negative to new participants instead of trying to encourage them to improve and learn. this lack of contributors then has a whole array of negative secondary effects, like less people reading the code for the project.
The "experts only" attitude is because, well, as we've seen with HeartBleed, this is VerySeriousStuff.
If the author instead put together a book on how a layperson could perform open-heart surgery, you're damn right that actual surgeons would jump all over it.
There is some strange pervasive attitude/arrogance in tech that all it takes to be good at something is to be smart and give it a try. Why learn the theory/fundamentals when you can just start coding?
For building a web app, sure. But security is not one of those things. You actually need to learn the fundamentals and theory, and even then, need lots of experience.
That's a very weird lesson to learn from the heartbleed bug. What I learned is cryptography experts should be consulted on matters of math and ignored on matters of software. Any non-zero application of software development best practices would have prevented the heartbleed flaw, including:
1: Don't implement features you don't need. Nobody needs TLS heartbeat. Nobody. Don't implement it until you have a use case and the calling code in hand.
2: Test the features you do implement. What happens if this field is the minimum? The maximum? A power of 2? A power of 2, less 1? Negative when treated as signed?
You know what else is hard? Writing a book on cryptography. It's all very well and good to point out problems, but there are probably more productive ways to teach people than simply point out what not to do.
That depends entirely on what type of book is being wrote. If I write a history textbook that goes into intricate detail about the Time Slip of 1662 and the Lost Years, and the eventual Realignment that resulted in the Great London Fire, am I being more useful than a critic who points out that my history textbook is full of factual inaccuracies?
I'll take one responsible author with one harsh-but-knowledgeable critic over a hundred would-be authors without the ability to sift useful content from polemic criticism.
I understand where you're coming from, but the author is the one who put this out in public. Publishing a book like this sends a strong message of "I am an expert, take what is written here as fact".
Maybe the tone could have been a little softer, but this should not have been done privately. The criticism of the work needs to be just as public as the work itself, so that people who might have been misled have a chance to see why.
Publishing a book like this sends a strong message of "I am an expert, take what is written here as fact".
And we, of the Internet age, should be shocked to learn this is no longer true! Eric Drexler once proposed that hypertext would save the world by allowing such peer review. Just what are we collectively missing when it comes to crypto?
It could have been couched like responsible disclosure where The Author got a 1 week grace period and worked with tptacek on getting a responsible message out.
The point of responsible disclosure is that it limits the damage done to users of the system in question by reducing the window in which the flaw is known and the systems are unpatched.
That doesn't apply for a book. Keeping the critique private for a week doesn't help the readers at all. In fact it harms them by keeping incorrect information in play and uncorrected for longer. Perhaps it softens the blow to the author's ego, but that is not at all what "responsible disclosure" is about. Helping out misinformed readers takes precedence over the author.
I agree with all your points. When I said treat this in a "responsible disclosure" method, I did really mean a grace period, for the authors sake[0]. Clearly the reasoning is not the same as a security issue, as you pointed out. I was trying to be a bit clever. My mistake.
That all said, I still think we can treat each other better. Honest question: was it necessary to destroy it in such detail? Was it necessary for the effort of attack on the "crypto box" front? It seemed personal.
[0] Contacting the author first doesn't necessarily preclude timely notice "this book is flawed" out to readers.
Yes, of the criticisms in that review, I think the "Crypto Box" one was among the most useful. He can fix that problem simply by renaming his library. The problem with calling it that is that there's also a library that provides a very carefully designed crypto_box: NaCl. NaCl was designed by someone who is simultaneously one of the world's best software security people and one of the best cryptographers. Repurposing the name like that is a little like a guy named Alan writing his own cipher and calling it "Alan's Encryption System".
What do you mean, "was it necessary to destroy it in such detail"?
If tptacek hadn't destroyed it in such detail, his review would have consisted of saying "Hey, this book is pretty bad; it's got some very serious issues, and makes some pretty terrible or misleading recommendations. My suggestion: do not read it".
Would that be better? Or would you be complaining that "Well geeze, it's not helpful to say that the book isn't good; you have to go into some detail about what the problems are so that everybody can learn!"
The idea of asking for LESS DETAIL in a criticism of a topic is bizarre. How much detail would you prefer?
While this is a valid course of action, I still feel it's up to an author to use due diligence in both researching the material, and seeking out expert advice before publishing.
Publicly discussing the flaws of a technical book actually helps a lot of people. I don't understand how it could possibly be better to have kept these comments private. By making them public, there are people who would have taken this bad advice who now know that it's bad advice. That makes us all more secure.
I really truly cannot understand the critique of an "experts only" attitude when it comes to technical books that make important recommendations for building critical systems. By all means, non-experts should experiment and build and learn. But non-experts definitely should not be giving out large quantities of advice in an authoritative tone.
> he instead chose to lambast kyle publicly, which doesn't really help anybody
It helps people who might have read the book and learned to do things the wrong way.
We can model this as "Kyle has disseminated harmful material, and tptacek is trying to contain the damage". Kyle's feelings, intentions, and hard work aren't irrelevant; but they're not what we should be focusing on.
Open source security projects have a hard time getting and keeping contributors because the expertise for this particular kind of work is difficult to develop.
Publishing a book like this sends a strong public signal of deep expertise.
I have not found tptacek to be overly rude or negative when offering advice to journeyman cryptologists. But a journeyperson should not necessarily be publicizing their how-to guides yet.
I'm sure the author is a nice guy. It is hard to put yourself out there like he has done. That said, when you put your name on something and put it in the public space, you have to be prepared for people to write these kinds of things. Furthermore, I think tptacek's blunt and at times snarky style is necessary to make his point. It is extremely hard to write clear critiques that don't sound harsh while at the same time clearly conveying the gravity of the situation. In short, tptacek can't afford the risk that softening his natural style means a major point will be missed. It's a bit like the old quote, "Sorry this letter is so long, I didn't have the time to make it short.". Politeness is a luxury one can't really afford when a book that has factual errors is already out there (and to be clear, I'm not qualified to assess whether this is true, I'm just speaking about the approach here). It is far better to write precisely what you're really thinking, than to couch it in all sorts equivocation and self-censorship.
Academic researchers get these kinds of critiques of their publications all the time. It's extremely useful to the whole academic process despite being infuriating and depressing. That said, most of those critiques happen before publication and in private. But as a book author, that's something one can control. If I were writing a book like this, my #1 worry would be that I was making claims or errors that would be held up on HN by folks like tptacek as evidence of my incompetence. I would therefore made it the highest priority to approach the most likely people to have an opinion to get them to review my draft ahead of publication. That's what people writing serious publications that have real world consequences do. Make no mistake: crypto is in this category. It's not like writing "The 4-hour Work Week", "Web Design for Programmers", or "JavaScript for Aspiring Ninjas".
If you're writing a book on a serious topic like security, you are presenting yourself as an expert and need to be able to stand up to the criticism. It goes with the territory.
It's good to stick up for people. It's less good to be thin-skinned on someone else's behalf.
Here, your attitude causes two problems.
First, you know and apparently like Kyle Isom, and so I presume you're also ready to tell me that he's an adult and a professional. Professionals do one of three things with criticism: ignore it, rebut it, or learn from it. My assumption has been that Kyle is choosing options (1) and (3) from that list. But here you are, inventing option (4): "get indignant about it". I wonder if you've thought about the extent to which people will attribute that response not to you, but to Isom.
Second, whatever you might think about the tone of my feedback, it's clear that Isom needs additional technical review for his book. Whipping up a totally unproductive us-versus-them narrative about "jerks" versus "open source" does the opposite: it generates drama. Even if you think my review was itself dramatic, piling more drama on doesn't make Isom's work more attractive to experts.
I'm not sure how big of a deal either of these issues are, but they're a bad habit for message board denizens. The exact same thing happened to Willem when he wrote his critique of the Akamai allocator, and Hacker News had a totally unproductive drama storm for a couple hours before Akamai (a) thanked Willem and (b) acknowledged that he was absolutely correct. Read the Akamai comments on the HN thread, and apply them here, substituting "Kyle Isom" for "Akamai", and I think you'll see that they apply.
Finally, I'll admit to being personally irritated by the claim that I operate from "experts only" logic with regards to cryptography. There are at last count something like twelve thousand people who have reached out to us for our free crypto challenges, and thousands of those people have gone on to solve multiple sets of challenges (something like 60 people have finished the first 6). Every damn one of those people is an email exchange that me, Sean, or Marcin had to have directly, on our own time, with no compensation --- the opposite of compensation, in fact, because we donate to charity when people finish them.
There are a lot of people on the Internet to whom you could direct the "experts only elitism" criticism regarding crypto. I am not one of them.
What's more annoying about that bogus critique is how it muddles a real issue. I'd like many more people to understand crypto and, particularly, what goes wrong when it's implemented naively. But I'd like far fewer people to plow ahead and implement their own broken stuff. The track record on amateur cryptography is bad, and what developers don't like to acknowledge is that the badness that work generates is an externality to them. People have in the real world been hurt, physically, because of broken amateur crypto. It is hard for me to take the hurt feelings of developers all that seriously by comparison.
Isom should thank tptacek for providing thousands of dollars in free consulting/editing work. He'll probably be a better engineer because of this feedback and the next edition of his book should be a lot better.
Isom doesn't owe me anything, but the notion that he might arises straightforwardly from the factionalizing that follows ginned-up outrage, which is point #2 I was trying to make above.
I disagree with your condemnation of a behavior while exhibiting said behavior. It shows that you're okay with drama so long as it's you creating it, but you're not okay with a dramatic response to your own drama-creating.
The accusation of elitism on your part is not a new one, I don't think, to you - I found myself levying the same accusation when you decided to single out the CryptoCat project as a distinctly "bad" project, due to the number of issues that came up during the most recent security review, despite the fact that it's one of a very select group of open source projects even undergoing such reviews.
You say things like, "amateur cryptography" when it makes little to no sense. This book wasn't written for free, it was actually professional crypto, even if it had fundamental problems; it's bad crypto, not amateur crypto. When you do things like that, it comes off as elitism, whether or not you're intending it to.
I disagree, but I'm also not interested in discussing Cryptocat on this thread, and I don't think you'd be doing Kyle Isom any favors by pushing the comparison further.
I'm just getting sick and tired of people in the crypto community dismissing projects because they're not done by one of the "ordained few".
Your criticisms of the book are indeed valid, but the obvious derision you apply when calling professional efforts such as this book and Cryptocat "amateur" is precisely the kind of behavior and attitude that keeps the state of crypto so backwards and slow, and is exactly the kind of drama you (correctly) lambasted earlier in this comment chain.
Reread the original comment to which you're effectively replying for what I think is a complete rebuttal to this comment, and, again, let me remind you that your comparison of Cryptocat and this book is unfavorable to the book's author.
Your assertion that tptacek's review doesn't really help anybody is patently false. It helped me by preventing me from making the mistake of purchasing this book.
I firmly believe that you shouldn't author a book in something if you lack the appropriate expertise. If you do so, you risk disseminating misinformation at scale, causing enormous harm.
"this pervasive "experts only" attitude is a big part of why "secure" open source projects have hard times getting and keeping contributors. "
Exactly
Not to mention the need to have to filter through all the BS criticism. I've read people arguing that there was no issue in having the e in RSA (the public exponent) equals to 1. Really.
You read that when SaltStack managed to set e=1 in their SSH replacement protocol, and what you read was SaltStack and its defenders arguing that the mistake wasn't as calamitous as it actually was. And you probably read about it because people like Coda Hale (and, yes, me) pointed it out on Twitter.
It eludes me how you turn someone's terrible custom crypto into a parable about how we should be nicer to custom crypto.
Wow...e=1? That makes me feel better about my biggest crypto goof, which I had assumed was the stupidest mistake anyone had ever made with RSA, but e=1 is worse.
Briefly, I was doing a single RSA encryption on the client and corresponding RSA decryption on the server as part of a login procedure, and using e=3 (which, at the time, was considered acceptable by most experts). Due to licensing issues the client code had to be all ours, so I was using an old arbitrary precision integer library I had written years before. It was not super fast. The multiplication wasn't too bad (Karatsuba), but division was the classical division algorithm. On the server there were no licensing issues, and I was using gmp.
So I had this "brilliant" realization. Why not do the division ON THE SERVER? The client could simply compute M^3 and send that to the server. The message would be 3 times longer but bandwidth was cheap. The server could then do the modular reduction.
I quickly made the change to the client and then started to revise the server code, when it occurred to me that since the client had made no use whatsoever of the modulus there must be a way to decrypt the message without using the modulus--like by just taking the cube root. Doh!
There's an interesting real-world RSA bug related to yours: in the absence of proper padding, it's possible that e=3 RSA of a small plaintext might not wrap the modulus. A similar cube root operation produces a signature that naive implementations (the ones that check the digest embedded in a signature block, but not the padding) will validate, despite the attacker lacking the signing key. That bug bit Firefox's NSS library; for a little while, it was possible to use a short Python script to forge any certificate.
(That bug is due to Bleichenbacher, who called it a "pencil-and-paper" attack in the rump session he presented it in).
e=3 RSA isn't insecure per se, but it does magnify the impact of other vulnerabilities, and so it's best avoided.
As my literal not-making-this-up favorite HN commenter and someone who has previously expressed an interest in crypto, I'd love it if sometime you could take some time to demolish our crypto challenges. I'd be happy to send them all at once to you.
I have signed up for the first set of challenges, although I doubt I'll do well on them. I'm not very good at that kind of challenge--with crypto I tend to do better on the theory side [1] than on the practical side when it comes to dealing with breaking things.
[1] by "theory" I mean vigorous and convincing hand waving and white board diagramming...
while the factual content of tptacek's review may be spot on, his overall tone is very negative and smacks of "only experts allowed" logic. while he could have easily helped improve kyle's book and shared these comments privately, he instead chose to lambast kyle publicly, which doesn't really help anybody: tptacek looks like a total jerk and kyle now has a lot of negative attention on (this version of) his book.
this pervasive "experts only" attitude is a big part of why "secure" open source projects have hard times getting and keeping contributors. it is par for the course for people to be super rude and negative to new participants instead of trying to encourage them to improve and learn. this lack of contributors then has a whole array of negative secondary effects, like less people reading the code for the project.