Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

181–190 of 255 posts

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

#181
post #167

Earlier quoted context omitted.

Isn't this the problem, then? People here seem to think you are , and by reading you I get the impression that they're right. I don't believe that you won't write a book because you're not qualified : you just don't want to write one. And that's a good enough reason. I think the community in general is very harsh towards anything related to cryptography. It's as if you shouldn't bother writing code unless you have ma…

I don't know how to say this other than directly: you're wrong. I shouldn't write a book on how to design cryptosystems, because I'm not qualified to do it, and I'll get things wrong. I can barely write an HN comment on crypto without being corrected by 'pbsd and 'cperciva. I am an odd duck, even for my odd little field: I'm a software security person who has spent a couple years getting decent at breaking crypto, an…

Maybe I was not clear. I'm not forcing you to write a book, nor saying you absolutely should.

My point is that if people like you, who are definitely more knowledgable than most in this area (most is very important here), communicate their experience, then everyone benefits. If nobody wants to write about crypto because nobody feels qualified, we're at a dead end.

When a person does write content, someone somewhere will tear it apart, for pretty good reasons: getting it right is very difficult, as you say. But that's precisely the point: to learn from our mistakes. We're not dealing with raw science, but real life implementations of theory, and this is where things usually break, as shown by your critique. The value of the book is pedagogical, not necessarily scientific.

If you have anything to say about crypto (and you clearly do), then say it. We're all the better for it! And contributions like the ones you gave here are needed. I just find the general attitude a little tiring, I'm not trying to force you into writing :)

Lastly, the most important thing, to me, is that I, as a chemist, can get on the internet and learn about these concepts from someone who understands them better than I do. Having a discussion about such topics is essential. Your contribution might not be in the deep theorems of academic cryptography, but they sure are appreciated by others like me. So if you ever want to write a book/pamphlet, go ahead, I'll buy it.

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

#182
post #181

Earlier quoted context omitted.

I don't know how to say this other than directly: you're wrong. I shouldn't write a book on how to design cryptosystems, because I'm not qualified to do it, and I'll get things wrong. I can barely write an HN comment on crypto without being corrected by 'pbsd and 'cperciva. I am an odd duck, even for my odd little field: I'm a software security person who has spent a couple years getting decent at breaking crypto, an…

Maybe I was not clear. I'm not forcing you to write a book, nor saying you absolutely should . My point is that if people like you, who are definitely more knowledgable than most in this area ( most is very important here), communicate their experience, then everyone benefits. If nobody wants to write about crypto because nobody feels qualified, we're at a dead end. When a person does write content, someone somewhere…

I understand. I'm making a distinction you don't care about, between books about designing crypto and books about breaking crypto. We're working on a book (it would be more accurate to say that I am cheerleading Sean and Alex on to write a book). It's just not a book that would teach developers how to build crypto.

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

#183

Earlier quoted context omitted.

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…

I'd love to chat with you about your book.

Thanks, but we're actively avoiding publishers.

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

#184
post #51

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.

It's unfortunate that it was too big for an HN comment, which would probably have prevented it being posted again as a topic. People who are genuinely interested in the book could have searched HN and found the original review. This thread just exists to bash/watch further bashing of the author/book.

It's fortunate that it was posted again as a topic, as I didn't see the original comment thread and wouldn't have read this review otherwise, and I learned things from it.

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

#185

Earlier quoted context omitted.

You trumpet NaCl's crypto_box and mentioned other language runtimes are deficient in one way or another, but what do you think about security of crypto in the Java standard library?

The JCA provides primitives, not whole designs. Primitives are rarely broken; even PHP mcrypt manages to successfully provide low-level crypto primitives. Most of the things that go wrong in cryptography happen at the points where two primitives join to form a more elaborate construction. The JCA isn't much help there. If you have the option to use NaCl, use NaCl. A Java-specific alternative to NaCl is Keyczar.

Speaking of Java crypto, I have a question. Is it possible a garbage collector might be dangerous to crypto code? I've seen it mentioned on HN that maybe we should be worried about implementing crypto code in a language with a non-deterministic GC, but sadly I can't find those comments right now.

TextSecure's crypto is implemented in Java, which is of course garbage collected. Some cursory Googling suggests that Java's GC will suspend the main execution thread during each GC op: http://javabook.compuware.com/content/memory/reduce-garbage-...

I'm guessing the concern is that an attacker might somehow discover a way to use the GC to recover sensitive info. It seems like having a GC might cause some other trouble, like making it hard to wipe sensitive data from memory once it's no longer needed: http://books.google.com/books?id=43pcI3in1DcC&pg=PA122&lpg=P...

Since TextSecure is currently believed to be secure and high-quality, then it must be true GCs aren't fundamentally dangerous to crypto code, right? (Or at least that Java's GC on Android isn't dangerous to crypto.) If a GC is dangerous to crypto code, then TextSecure would be vulnerable to those dangers.

Do you happen to know whether cryptographers as of 2014 generally believe GCs are/aren't/might be dangerous to crypto code? Are there any known attack vectors or proofs of concept? (It would be awesome if anyone could point out any whitepapers on the subject.)

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

#186

Earlier quoted context omitted.

> If something legitimately makes you stop and stare with your mouth hanging open, it is OK to say "this statement made me stop and stare with my mouth hanging open." It's okay if you are writing a story about your personal reactions. It's irrelevant if you are writing a serious critique, which should be about the content, not about your emotional response to it (assuming it is a critique of an informative work -- ob…

Sure, it's irrelevant. It adds some color, but it's unnecessary. But who cares? The complaints are not "this writing could be tighter, it wastes words on unnecessary side notes." They are, "oh my god you're hurting this poor fellow's self esteem with your tone!" It's ironic that these critiques of this review are much dumber than the review's critiques of the book, and implicitly hold a fairly off-the-cuff internet c…

Out of curiosity, how could it have been better?

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

#187

Earlier quoted context omitted.

The JCA provides primitives, not whole designs. Primitives are rarely broken; even PHP mcrypt manages to successfully provide low-level crypto primitives. Most of the things that go wrong in cryptography happen at the points where two primitives join to form a more elaborate construction. The JCA isn't much help there. If you have the option to use NaCl, use NaCl. A Java-specific alternative to NaCl is Keyczar.

Speaking of Java crypto, I have a question. Is it possible a garbage collector might be dangerous to crypto code? I've seen it mentioned on HN that maybe we should be worried about implementing crypto code in a language with a non-deterministic GC, but sadly I can't find those comments right now. TextSecure's crypto is implemented in Java, which is of course garbage collected. Some cursory Googling suggests that Java…

I think that the concern crypto engineers have with garbage collected runtimes is held in tension by the equal and opposite force of their concern about memory corruption bugs in C. It's a concern, but an inchoate concern.

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

#188

Earlier quoted context omitted.

No, I'm not even close to qualified to write that book.

You trumpet NaCl's crypto_box and mentioned other language runtimes are deficient in one way or another, but what do you think about security of crypto in the Java standard library?

This might help:

> I reviewed several SSL implementations for coding style: OpenSSL, NSS, GnuTLS, JSSE, Botan, MatrixSSL and PolarSSL. I looked at how buffers are handled in parsers and writers. Of all of them, I think only JSSE, i.e. pure Java, can be trusted to be free of buffer overflows. It suggests that a good webserver for security-critical applications would be Tomcat, without native extensions.

http://tstarling.com/blog/2014/04/ssl-implementations-compar...

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

#189

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. When did this community become more concerned with tone than correctness? The top of this thread is filled 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 o…

Perhaps the reason people are not commenting on the correctness as much is that it is, broadly, correct. It's quite difficult to add to a discussion when it's already right - there's no debate to be had.

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

#190

Earlier quoted context omitted.

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…

I never said what my tone was on the bus -- it was blunt and matter of fact. My observation was about the young man's reaction . I take exception to your post, as it suggests I said something I didn't.

My point was more about the way you leapt from tptacek's review of the crypto book to the incident on the bus, which implies that they're comparable situations, when really they're not. Not all cluelessness is equal.

> I take exception to your post

I demand satisfaction! Pistols at dawn, my good fellow! Pistols at dawn!

Post reply on HN