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

131–140 of 255 posts

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

#131

Post by MattRogish »

jvehent wrote: post #128
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.

It's not specific to cryptography. There is a hierarchy in all fields: 1. Top researchers come up with algorithms and techniques - The research corpus reviews them 2. Top programmers implements these techniques - The programmers communities review them 3. Top engineers write books to explain these techniques - which everybody else relies on in their tools 1 knows more than 2 which knows more than 3. But each group ne…

When you see someone repeatedly walking up the down escalator you don't give them an attaboy when they reach the top. You tell them to use the right escalator.

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

#132

Post by berdario »

natdempk wrote: post #92
berdario wrote: post #90

Can someone explain me this? > In considering RSA, the book recommends /dev/random, despite having previously advised readers to avoid /dev/random in favor of /dev/urandom. The book was right the first time. From "man 4 urandom": > A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vuln…

Here's the blog post that always gets linked when this comes up: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

Thanks, I never read it before.

Anyhow, its conclusions seem to be mistaken to me:

> It’s also a bug in the Linux kernel. But it’s also easily fixed in userland: at boot, seed urandom explicitly. Most Linux distributions have done this for a long time.

If you're an application developer (of something that runs very early in the boot process) but you're not making your own distro, and you can't trust your distro (I guess that since a lot of factorable keys existed, "Most Linux distributions have done this" might not actually hold true or count to a good enough percentage) you don't really have anything else that you can rely on to seed /dev/urandom explicitly

I'd think that the correct approach is to use urandom on everything but linux (after all, as long as your application isn't a blocker for the boot of the system, it doesn't seem terrible to wait for /dev/random)

Also, reading and blocking from /dev/random seems akin to failing early and explicitly (in the case where blocking on read is actually a problem), while reading urandom when not initialized seem to be a silent failure.

But I'm not going to write software that has to read from either device anytime soon, so don't panic if I'm mistaken :)

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

#133

Post by karmajunkie »

nkozyra wrote: post #87

As someone finishing the final edits of a technical book (on Golang, at that) this is the kind of thing that horrifies me. I want to go through every single chapter and rewrite it to stave off the imaginary critics in my head who will undoubtedly tear it apart.

Friendly advice, find a few people you respect on the subject and ask them to review it. Wards off a lot of the anxiety and will generally make your work a lot better.

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

#134

Post by raverbashing »

tptacek wrote: post #123
raverbashing wrote: post #80

Those with glass ceilings shouldn't throw stones While criticism is good, the condescending way it is presented, as well as being overly critical are bad. Example: "Total undue reverence for NIST and FIPS standards; for instance, the book recommends PBKDF2 over bcrypt and scrypt (amusingly: the book actually recommends against scrypt, which is too new for it) because it's standardized." I know people love scrypt and…

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?

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

#135

Post by jessaustin »

lkozma wrote: post #18
austinz wrote: post #12

I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine. In all cases you have a system whose failure can result in anything from monetary loss to death (for an example of the latter, faulty cryptographic software used by dissidents in repressive countries). In all cases you use a combination of…

The reason why crypto might be even harder than the other engineering tasks you mention is that in those the "adversary" is indifferent, not actively trying to exploit every loophole you might have left. You might build a bridge that has some small weakness, but no-one will come and stack weights in the exact pattern that exploits the weakness and makes the bridge collapse.

Yes gravity and metal are more predictable than a creative adversary:

http://wondermark.com/406/

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

#136

Post by maxerickson »

berdario wrote: post #132
natdempk wrote: post #92

Earlier quoted context omitted.

Here's the blog post that always gets linked when this comes up: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

Thanks, I never read it before. Anyhow, its conclusions seem to be mistaken to me: > It’s also a bug in the Linux kernel. But it’s also easily fixed in userland: at boot, seed urandom explicitly. Most Linux distributions have done this for a long time. If you're an application developer (of something that runs very early in the boot process) but you're not making your own distro, and you can't trust your distro (I gu…

Seed it from /dev/random.

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

#137

Post by tptacek »

runn1ng wrote: post #34

> The book actively recommends public key cryptography, because of concerns about key distribution. Again: bad strategy. Cryptographers use public key crypto only when absolutely required. Most settings for cryptography don't need it! Public key cryptography multiplies the number of things that can go wrong with your cryptosystem. Can I ask why? What is so dangerous with asymmetric crypto compared to symmetric crypto…

The biggest reason is that public-key crypto is "just a math problem" to an extent that isn't true of symmetric crypto. Diffie Hellman, for instance, is just an RNG and a couple modexps. There's no machinery of repeated substitutions and permutations and nonlinearities to hide your mistakes.

Another big reason is that public-key algorithms are parameterized to an extent symmetric systems aren't. Two random numbers is all you need to safely encrypt something with AES. Diffie Hellman, the simplest of the public key algorithms, needs a prime, a generator, and random private keys with particular relationships to those parameters.

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

#138

Post by tptacek »

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?

The bcrypt library.

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

#139

Post by tptacek »

sillysaurus3 wrote: post #130
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.

If I had written a book on implementing cryptography I've been throwing $20 bills at my monitor so that your book will start downloading, but it doesn't seem to be working. But really, you should write one.

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

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

#140

Post by tptacek »

raverbashing wrote: post #125
conformal wrote: post #88

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…

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

Post reply on HN