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

81–90 of 255 posts

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

#81

Post by dvanduzer »

Jabbles wrote: post #51
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.

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.

This is an incisive criticism, but it's extremely educational in its own right. I would not have read it otherwise.

When working through basic knowledge to mastery of a topic, attempting to teach someone else is an extremely effective way to organize your thoughts and learn yourself. This is why graduate students teach undergraduate students.

The author of the original book shouldn't feel shame for making the mistake of working toward mastery of the topic. But racing to publish is dangerous when the topic is as serious as (heart surgery or) cryptography. A stern warning is worth repeating.

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

#82

Post by Rubikan »

exDM69 wrote: post #56
zatkin wrote: 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…

Yeah, but searching for the actual word is much easier than searching the acronym. Take MAC for example (tried out with german google, so your experience may vary).

I get a cosmetics site, apple.com and store.apple.com, wikipedia article about the mac adress and a clothing site. Message Authentication Code is nowhere to be found.

Yes, I took one of the harder ones, AES is on the first position, but still it is nice to know the words behind an acronym.

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

#84

Post by amoonki »

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

As mentioned earlier in this thread, eople who don't know now have some keywords to google with.

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

#85

Post by StavrosK »

Nursie wrote: post #83
StavrosK wrote: post #69

Earlier quoted context omitted.

Still waiting for Crypto II :(

Me too. How long overdue now? 2 years? Crypto 1 was awesome, am impatient to do more!

Yeah, they're just pushing it back :( Crypto I was the only course I couldn't get enough of, I did all the exercises and all the extras and got 100% at the end, it was fantastic. Dan Boneh explained everything very very well.

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

#86

Post by yread »

jimktrains2 wrote: post #67
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…

Possibly speed? Symmetric crypto is fast, and is often hardware accelerated. Asymetric is slow and not accelerated. Not as big an issue with ECC, but RSA also has much larger block sizes, increasing the size of small payloads. It's been my experience that Asymmetric is used for kex (key exchange) or key agreement or signing, but encryption is done using a symmetric algorithm.

But you would be using asymmetric only for exchanging keys for symmetric encryption.

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

#88

Post by conformal »

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 lot of negative attention on (this version of) his book.

this pervasive "experts only" attitude is a big part of why "secure" open source projects have hard times getting and keeping contributors. it is par for the course for people to be super rude and negative to new participants instead of trying to encourage them to improve and learn. this lack of contributors then has a whole array of negative secondary effects, like less people reading the code for the project.

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

#89

Post by jerf »

jacquesm wrote: post #49
rkangel wrote: post #43

Earlier quoted context omitted.

> 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. Couldn't agree more. The problem is that for any bridge that gets used, every structural engineer signing off is going to have been educated and experienced to the extent that they are Chartered (or equivalent), the plans for the bridge…

How will regulation take care of bad crypto? Even experts get it wrong with some regularity (of course not as often as noobs, but still).

The problem with regulation is that one must first establish who is capable of regulating correctly. There's no such thing as abstract regulation that simply exists.

The entities that would most likely do the regulating already exist, but I'm unconvinced any of them would actually improve the situation. For instance, see http://blog.cr.yp.to/20140411-nist.html . What real group of people could really regulate cryptography? What real group of people's regulations could actually bring benefits to the field, rather than rubber stamping, government meddling for the NSA, and an emphasis on quantity over quantity?

If you can't answer that, I'd suggest staying away from a reflexive "regulation" standpoint.

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

#90

Post by berdario »

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 vulnerable to a cryptographic attack on the algorithms used by the driver.

In fact, using /dev/urandom is one of the causes of the creation of weak ssh key, found in this research: https://factorable.net/

So: Why is /dev/urandom the correct choice over /dev/random ?

Post reply on HN