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…
Tptacek's Review of "Practical Cryptography With Go"
71–80 of 255 posts
Re: Tptacek's Review of "Practical Cryptography With Go"
#72Earlier 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).
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"
#73From 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…
Re: Tptacek's Review of "Practical Cryptography With Go"
#74Re: Tptacek's Review of "Practical Cryptography With Go"
#75Does 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.
Re: Tptacek's Review of "Practical Cryptography With Go"
#76I 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.
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"
#77I 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"
#78From 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)
Re: Tptacek's Review of "Practical Cryptography With Go"
#79I 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.
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"
#80While 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.