Live data from Hacker News

Tptacek's Review of "Practical Cryptography With Go"

gist.githubusercontent.com

51–60 of 255 posts

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

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

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

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

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

#53
post #11
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…

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…

What I have trouble with is the spelled out versions. Every time I see some stupid newspaper article that says "HyperText Markup Language" or whatever, it takes my brain two or three seconds to process it and go "oh, duh, HTML".

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

#54
post #33

can someone explain this? * This book, I am not making this up, contains the string: "“We can use ASN.1 to make the format easier to parse". Last time I had something to do with ASN.1 was years ago but it seemed to work well, libraries were full featured and cross-language interop was ok. What am I missing that makes ASN.1 bad ? Or is the critique to an attempt to write a custom ASN.1 serializer/parser?

> Last time I had something to do with ASN.1 was years ago but it seemed to work well, libraries were full featured and cross-language interop was ok. What am I missing that makes ASN.1 bad ? Didn't you know? If a web developer out of high school cannot read a format at first glance, it's obviously over-engineered and useless and anyhow everybody should always use JSON anyways.

tptacek is hardly a web developer straight out of high school.

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

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

One symmetric cryptography method are one-time pads. Essentially you generate a truly random key (for example by observing some decay process) that has the same length as the maximum length of a message you might want to send and distribute the key to the receiver in advance. You encrypt the message by modular vector addition and decrypt it by subtracting the key. If you use the key only once and it is random, there can't be any attack on this method.

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

#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 in the list.

So if someone doesn't know what these things stand for, they're going to have to go to Wikipedia to check it out anyway, the words behind the acronym are almost as confusing as the acronyms themselves.

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

#58

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.

I think the tone is what makes it tougher than it needs to be, not the factual content. Props to the author for just looking at the content and not at the way in which it was delivered. Props to Thomas for taking the time to review the book.

This condescending tone seems to be mandatory for karmic users of over 100K points :)

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

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

Agreed. I don't often flag submissions but I'll be flagging this one.

Most of us already read the review anyway.

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

#60

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.

I have faith the next edition of the book will withstand tptacek's criticism much better.
Post reply on HN