Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

Post reply on HN
Print view View original

151–160 of 255 posts

Re: Tptacek's Review of "Practical Cryptography With Go"

#151

Post by leoc »

stcredzero wrote: post #96
stavros wrote: post #66

Earlier quoted context omitted.

You're being downvoted, but I agree that a greater amount of tact would have been warranted. Phrases like "I am not making this up", "argh!" and "huh?" add nothing to the review, but only serve to make it more personal, and I say this as a guy who also has very little tact.

There has been a cultural shift in recent years. None of tptacek's observations are adhominem. But there is now an expectation that one tone down the description of one's own reaction. I suspect this is often a conflict between the expectations of the children of helicopter parents and my generation. (1) Sorry, but I have a right to an emotional reaction to your content and a right to describe it, especially if the r…

Amost all aggressive reactions are partly contrived and controlled, even if they're occasioned by genuine emotion in the actor. You can see this from the fact that you very rarely see someone give a strongly hostile or contemptuous emotional reaction to their boss or someone else whose reaction they fear. Somehow the guys who just have strong feelings, or just have to tell it like it is, manage to tell it in a much more circumspect manner, or not at all, when letting fly would have unpleasant consequences for them rather than whoever they're going at.

Re: Tptacek's Review of "Practical Cryptography With Go"

#152

Post by mbrameld »

conformal wrote: post #88
jgrahamc wrote: post #42

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

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 l…

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.

Re: Tptacek's Review of "Practical Cryptography With Go"

#153

Post by tptacek »

MetaCosm wrote: post #144
tptacek wrote: post #112

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.

Most of your review seemed to be utilitarian and useful for a second edition. That is awesome, the way you structured it means the author could use a ton of it, and it gives readers specific things to be aware of. Sincere thanks for that. That said, you first point seemed silly. Simplified, partial and building block examples are used in almost all fields to facilitate teaching (including among medical students and s…

The author doesn't demand that his readers implement AES or SHA2 directly. So, what I would do is start with a simple, secure design based on an AEAD like AES-GCM, which is also in the Golang standard library. I would accompany that design with very strong warnings that substituting AES-GCM for anything else is likely to destroy the security of the design. Then, when I wanted to teach about generically composed MACs, my HMAC example would involve replacing AES-GCM with AES-CTR+HMAC. At no point in the book would the focus of one of my chapters be a design that was dreadfully insecure.

I would also divide the book into two parts, the "easy" part and the "hard" part. The "easy" part would get readers to the point where they can safely use TLS, reliably PGP-encrypt something, hash a password, and invoke NaCl (which is part of the go.crypto package). I would probably spend a whole chapter on how to use Golang's TLS library, for instance. Most readers that are picking the book up so they can solve some business problem would probably never need to get past the "easy" part, and I would encourage them not to.

I would remove from the "hard" half of the book protocols that were insecure. An unauthenticated DH exchange is a poor basis for a cryptographic transport. Slash, cut, gone. A naive password challenge-response protocol doesn't solve anyone's business problems. Slice, snip, gone. In their place, I'd probably add more discussion of key exchange algorithms, with particular attention paid to how easy they are to get wrong.

Re: Tptacek's Review of "Practical Cryptography With Go"

#154

Post by bch »

mikeash wrote: post #120
bch wrote: post #104

Earlier quoted context omitted.

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 auth…

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.

Re: Tptacek's Review of "Practical Cryptography With Go"

#155

Post by goblin89 »

logicallee wrote: post #70
chipaca wrote: post #32

Earlier quoted context omitted.

Remember that being wrong about something feels exactly the same as being right about something, so (extending "being wrong" to "being ignorant") unless somebody tells them they won't know they still have stuff to learn.

>Remember that being wrong about something feels exactly the same as being right about something Not if you extend being wrong to being ignorant, no. When you're right about something in the sense of not being ignorant, you understand all the discussions and news easily, you know exactly what everyone is talking about, including reading academic articles on the subject, etc. When you're wrong about something your wro…

Don't forget about Dunning–Kruger effect, though. One doesn't necessarily know they're ignorant.

Re: Tptacek's Review of "Practical Cryptography With Go"

#157

Post by tptacek »

archgoon wrote: post #147
tptacek wrote: post #112

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.

While reading your review, one of the main criticisms seems to be that the it's not made sufficiently clear that the code as written is insecure. In keeping with the philosophy of being hands on; would the book be improved if after introducing the code in the first section, have the reader implement an exploit for the same code?

I feel comfortable with the idea of writing a book showing people how to break badly-implemented crypto designs, so much so that Sean, Alex, and I are in fact writing that book; it'll be a "pay-what-you-want" directly to a preferred charity. If anyone can point us to someone who will take our money to expertly typeset a giant text file, that would be helpful.

I do not feel remotely comfortable with the idea of writing a book containing prescriptions on how to design a cryptosystem. We're wary of doing that even for our clients, where we know all of the context and the threat model that the proposed system would face, and who will actually build it, and that we'll get paid to review the resulting implementation. I don't know how to solve that problem for strangers.

Other people do. They are much better than I am. When Trevor and Moxie write the book on why they chose the TextSecure primitives that they chose, I'll be first in line to buy.

Re: Tptacek's Review of "Practical Cryptography With Go"

#158

Post by angersock »

tptacek wrote: post #157
archgoon wrote: post #147

Earlier quoted context omitted.

While reading your review, one of the main criticisms seems to be that the it's not made sufficiently clear that the code as written is insecure. In keeping with the philosophy of being hands on; would the book be improved if after introducing the code in the first section, have the reader implement an exploit for the same code?

I feel comfortable with the idea of writing a book showing people how to break badly-implemented crypto designs, so much so that Sean, Alex, and I are in fact writing that book; it'll be a "pay-what-you-want" directly to a preferred charity. If anyone can point us to someone who will take our money to expertly typeset a giant text file, that would be helpful. I do not feel remotely comfortable with the idea of writin…

Any chance of just releasing it as big .txt balls, MaTaSaNo_Crypto_2_of_7.txt , with glorious ascii art at the top?

You know, for old times' sake?

Re: Tptacek's Review of "Practical Cryptography With Go"

#159

Post by cabinpark »

tomp wrote: post #41
eproxus wrote: post #11

Earlier quoted context omitted.

I usually make it a habit to spell out abbreviation the first time I use them and include the abbreviation in parentheses, like Transport Layer Security (TLS). Later, after the first introduction I can safely assume people know it, like TLS. Even for technical documents, if you expect your target audience to be familiar with the domain, nobody remembers every abbreviation every time. It also helps new readers to quic…

This hardly makes any sense: - for the readers who already know the abbreviation, it's a waste of space and time - for readers who don't, the words won't tell them much either - Transport Layer Security tells you about nothing about what TLS really is - besides, for those who are really interested, they can always look it up on Wikipedia (that way, they will actually understand it).

And yet in every scientific paper I have read they still spell out the abbreviations the first time. And these are written by experts in the field. Why? Because it removes ambiguity and makes it completely clear what you are talking about. What if in 20-30 years the acronyms change or fall out of favour? It happens all the time.

Re: Tptacek's Review of "Practical Cryptography With Go"

#160

Post by smacktoward »

stcredzero wrote: post #96
stavros wrote: post #66

Earlier quoted context omitted.

You're being downvoted, but I agree that a greater amount of tact would have been warranted. Phrases like "I am not making this up", "argh!" and "huh?" add nothing to the review, but only serve to make it more personal, and I say this as a guy who also has very little tact.

There has been a cultural shift in recent years. None of tptacek's observations are adhominem. But there is now an expectation that one tone down the description of one's own reaction. I suspect this is often a conflict between the expectations of the children of helicopter parents and my generation. (1) Sorry, but I have a right to an emotional reaction to your content and a right to describe it, especially if the r…

I would argue that it's not as simple as

> I have a right to an emotional reaction to your content and a right to describe it, especially if the reaction is grounded in objective technical reality

... because while you have rights, being a person who participates in a civilized society means you also have responsibilities, and one of those responsibilities is to interact with people in ways that are appropriate to the situation.

And "appropriate to the situation" changes depending on the nature of the situation. The less serious the situation, the less appropriate a volcanic reaction becomes. Nobody's going to disapprove of you if you start screaming at an airline pilot who you see snorting coke on his way to the plane. But lots of people will disapprove of you if you lay down the same reaction on some poor kid behind the counter at McDonald's because he forgot your French fries.

In the case of this review, I would say tptacek's tone is appropriate, because security is Serious Business (as we should all know, especially after last week); getting it wrong can result in people getting robbed or even killed. So if you're going to put yourself forward as a teacher of crypto, and you're teaching people things that aren't true, you're doing real damage and should be glad a good yelling-at is the worst punishment you have to suffer. But that doesn't mean that the same tone would be appropriate if taken with the kid on the bus, because "annoyingly oblivious" is a long chalk from "could get people killed."

Post reply on HN