Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

111–120 of 255 posts

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

#111
post #56
post #9

For those of you who don't know what the acronyms stand for, I've compiled a list, in order by their appearance: 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…

Nice that you composed this list but quite honestly, it isn't very helpful to know what the letters in the acronyms stand for without knowing what these things actually are. Take AES for example, "Advanced Encryption Standard" doesn't really mean anything. AES is a block cipher, also known as Rijndael. CTR and CBC are block cipher modes. RSA is a public key cryptosystem, etc. The same applies for most of these things…

I think the list was helpful as well. I know quite a few of those acronyms and what hey mean, but a few I did not know.

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

#113
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…

Or as my 4th grade teacher used to say "Don't be sorry, be right".

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

#114
post #104

Earlier quoted context omitted.

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

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.

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.

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

#115
post #102
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.

"I am not making this up" is a succinct way to say "this was a really stupid string for the book to contain". Tptacek could have chosen to say that differently, but it does add value as written. I have no idea what ASN.1 is; simply telling me that the book contains that string doesn't mean anything to me. Telling me that it was a stupid thing to say doesn't teach me about ASN.1 or crypto, but it does teach me about t…

Sure, but there's a difference between "this book is really bad, it contains errors and wrong advice, I would advise against it and avoid it" and "goddamn this is literally the stupidest book that has ever been written". They convey the same amount of information, but the author's feelings are not hurt equally.

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

#116
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 don't know, I have problems with these things. I never know who's wrong, should the author not take it personally, or should the reviewer be tactful? I guess both.

Why hurt someone when you can avoid it?

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

#117
post #98

tptacek makes a number of good points but I find it hard to agree with this one: > there is concern that the NIST curves are backdoored and should be disfavored and replaced with Curve25519 and curves of similar construction. 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 "…

I actually agree with most of this.

The issue with the NIST P- curves is that there's no good reason to trust them. And, for what it's worth, being ahead of academia on pure math isn't science fiction; NSA employs a lot of mathematicians. But the notion of a backdoor in the NIST curves is totally speculative.

Here's what I was trying to capture:

http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf

Despite its very weird submission as a story to HN, what you'd been reading was just a very long HN comment; I wrote it in a single draft and in the style I would use when writing a comment.

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

#118

Earlier quoted context omitted.

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 don't know, I have problems with these things. I never know who's wrong, should the author not take it personally, or should the reviewer be tactful? I guess both. Why hurt someone when you can avoid it?

I have a personal problem with ASN.1, and with authenticate- then- obliviously- decrypt. I don't know the author of this book at all and reject the implication that the review had a personalized tone.

Having said that: had I written the "review" as an actual "review", and not as an oversized HN comment that I had to make a Gist out of to get it onto the site, I would have written it more carefully.

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

#119

Earlier quoted context omitted.

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…

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/fun…

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?

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

#120
post #104

Earlier quoted context omitted.

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

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.

Post reply on HN