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

211–220 of 255 posts

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

#211

Post by StavrosK »

mpyne wrote: post #209
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.

Your comment actually made me read the review since it seemed really bad... but after reading it I'm just not seeing the problem. The "I am not making this up" thing came in the context of recommending ASN.1 for instance. If that were a chess match commentary, this is where the scorekeeper would have put a "??" after the move to note the shock. And note what tptacek's comment was not : It wasn't a bunch of personal a…

I don't think either jacquesmattheij or me said this was really bad, he just said that the tone could be better and I agree. I think people are reading things into our comments.

I agree that it wasn't especially bad, it could just be worded a bit better to spare feelings.

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

#212

Post by tzs »

tptacek wrote: post #140
raverbashing wrote: post #125

Earlier quoted context omitted.

"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 crypt…

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!

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

#213

Post by diminoten »

tptacek wrote: post #210
diminoten wrote: post #207

Earlier quoted context omitted.

Yes, because amateur projects generally undergo third party security reviews.

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.

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

#214

Post by tptacek »

tzs wrote: post #212
tptacek wrote: post #140

Earlier quoted context omitted.

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

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…

Yes, that actually happened:

https://github.com/saltstack/salt/commit/5dd304276ba5745ec21...

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.

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

#215

Post by mpyne »

raverbashing wrote: post #134
tptacek wrote: post #123

Earlier quoted context omitted.

This is silly. There is no advantage to using PBKDF2 other than to placate PHBs. PBKDF2 (as commonly implemented, with HMAC-SHA2) is faster than bcrypt and scrypt and particularly straightforward to implement in GPU crackers. bcrypt is also approximately the same age as PBKDF2. And, finally, standardization is a very poor substitute for security analysis. PKCS1v1.5 is also a standard. If you want to argue against bcr…

I'm not arguing against bcrypt/scrypt per se. I'm arguing that there may be advantages in using standardized methods (for interoperability) and especially implementations. Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library" for Ruby/Node that someone just posted to github? Oh what do you mean that's not how you read secure random numbers?

> Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library"

What kind of dilemma choice is that? It should rather be:

"Which one is safer, using PBKDF2 from a known implementation or bcrypt from a known implementation?"

But even that question is erroneous. After all, why shouldn't we just use PBKDF2 from RSA's known BSAFE implementation? What could possibly go wrong with that?

Or if you don't like RSA because of da Feds, why not use the known-good OpenSSL for securing data in motion instead of something new and untested like stunnel or spiped?

Known implementations are a very good consideration factor. You should use TLS (though maybe not OpenSSL's) in general instead of designing your own secure transport. But being from a known implementation should not be the only factor you consider otherwise you're just cargo culting. You have to understand pros/cons of each solution, even if that means you have to learn a little bit about the problem space.

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

#216

Post by tptacek »

diminoten wrote: post #213
tptacek wrote: post #210

Earlier quoted context omitted.

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

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.

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

#217

Post by diminoten »

tptacek wrote: post #216
diminoten wrote: post #213

Earlier quoted context omitted.

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

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.

I know you think it's unfavorable to compare the two, but that's the entire problem.

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

#218

Post by scott_s »

duaneb wrote: post #148
scott_s wrote: post #110

Earlier quoted context omitted.

When you are writing about a difficult subject, you should invite reviews from experts to vet your work.

I'm not disagreeing. I'm just pointing out that a critic is much less useful than an author.

If I wrote a book on brain surgery, the critics would be much more useful than the author.

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

#219

Post by dragonwriter »

mikeash wrote: post #176
dragonwriter wrote: post #164

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…

That's pretty much a TL;DR of what I was saying in the post you responded to (note the last paragraph).

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

#220

Post by saidajigumi »

tptacek wrote: post #153
MetaCosm wrote: post #144

Earlier quoted context omitted.

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

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

IMO, it's exactly this kind of strong advice early on that would be of great benefit would-be crypto developers. They need it drilled in as early as possible that the canyon-like pitfalls lie in the compositional problems of building a working cryptosystem. This is really a domain where just-ship-it cowboy coding becomes a massive liability.

Post reply on HN