Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

71–80 of 255 posts

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

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

"Message Authentication Code" is a lot easier to google for than MAC, and more meaningful in itself too. I found the list helpful.

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

#72
post #41
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).

> Transport Layer Security tells you about nothing about what TLS really is

Doesn't it? Even a complete tech-illiterate can glean some meaning from the word "security".

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

#73
post #19

From tptacek's comment, it sounds like the author of the book may just be an inexperienced practitioner of cryptography who's only crime is to be too eager to spread what they've learned. Someone who picked up the basics from a few Wikipedia articles here, a few papers there, a couple open source projects here and there... they're smart, so they're not completely clueless about the field, but they just don't have the…

As bad as it may seem I've found that saying incorrect things results in more learning than staying quiet so I often say incorrect things but things I think are true. I'm embarrassed when I'm wrong but I always learn from it. I also ask "why?" a lot and "what is that?" if it makes sense to (or just Google it later). I learn this way. It helps solve ignorance. It doesn't make me a faster thinker which is something I may not be able to fix, and it doesn't help improve my motivation to learn more which I need to do more of instead of playing video games or creating things.

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

#75

Does Tptacek have a list of books/articles he would recommend to the Crypto neophyte? I'm talking about books which could be considered de facto standards like Knuth's TAOCP or Steven's TCP/IP books.

He replied to this question here: https://news.ycombinator.com/item?id=7581885 (http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp...)

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

#76
post #52
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…

What I don't understand why most crypto libraries are then implemented in an inherently unsafe language. I feel something like the secure subset of Ada would have been much more apropriate.

Because to be usable it needs to be fast (and portable), and for a long time those constraints basically meant C - possibly not any more.

But let's not kid ourselves, reimplementing a library the size of OpenSSL in a new language, or even the same one, is not a trivial matter. We're talking about a $10m+ investment, who's going to pay?

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

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

[deleted]

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

#78
post #19

From tptacek's comment, it sounds like the author of the book may just be an inexperienced practitioner of cryptography who's only crime is to be too eager to spread what they've learned. Someone who picked up the basics from a few Wikipedia articles here, a few papers there, a couple open source projects here and there... they're smart, so they're not completely clueless about the field, but they just don't have the…

An "inexperienced practitioner of cryptography" should not be writing a book about cryptography. It's great that such a person is learning, but you shouldn't be trying to pass on such information at that stage. (I don't know the author either)

An experienced publisher shouldn't be printing said book either.

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

#79
post #18
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.

Engineering does have to deal with real adversarial threats.

Just on example I've found: https://www.nae.edu/Publications/Bridge/Terrorism/AnEngineer...

"The second relates to the design of structures. It is time for engineers and architects to get together to devise new structural forms that offer a higher degree of protection not only against terrorist attack, but also against other hazards. There is much to be learned from what happened in Nairobi and Dar es Salaam, in Oklahoma City, and at the World Trade Center. Similarly, retrofitting of existing structures needs to be studied systematically, as it can reduce, at modest or virtually no cost, the potential for damage."

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

#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 bcrypt, and have been proven safe so far, but there are advantages to use standardized methods. An implementation can make something less safe than the standard.

Post reply on HN