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

41–50 of 255 posts

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

#41

Post by tomp »

eproxus wrote: post #11
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…

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

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

#42

Post by jgrahamc »

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.

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

#43

Post by rkangel »

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…

> 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 have to be approved by planning authorities and a thorough documentation and review process has been gone through, before the first drop of concrete has been poured. And once its up, it's tested, and inspected regularly. As every engineer on the project has necessarily been educated they know how hard it is and what the pitfalls are.

Bad crypto results from the fact that there is no need for any of the above requirements to be met. Any old engineer might think they can produce a good implementation, design it, put it into production and have systems secured by it, without being aware of the potential problems they're causing.

The free world of the internet is a wonderful thing, but regulation isn't entirely a bad thing either.

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

#46

Post by izacus »

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…

Well, the lack of good documentation for libraries is also hugely problematic.

For example, I'd call OpenSSL documentation "criminally bad" to the point where it actively tries to coax the user into making a mistake - there is no central point of good practices for common use cases (e.g. sending a AES256-CBC encrypted block of data securely with shared key, using pub/private key, etc.) and the docs regulary don't mention the proper way of initializing different datastructures and modules (like RNGs) when they're mentioned. Even finding out how to properly initialize everyting to do a standard PBKDF#2 password derivation is a huge chore that requires reading through tons of badly formatted documents (or copying a random piece of code from StackOverflow which may or may not be secure). That makes even highly secured libraries a minefield where you can easily introduce huge security flaws without even knowing that you did so.

And as long as the excuse for that is "well, you just need few years of studying all crypto background" we'll be seeing security breaches everywhere - developers mostly just aren't prepared to spend so much time learning the crypto field or spend alot of money on security experts. In the big picture that's a huge issue - too many devs just opt to copy random pieces of code from StackOverflow, which can have very glaring security flaws or are simply not secure for the devs usecase.

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

#47

Post by nailer »

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 a tough thing for anyone to read: it's browserWidth wide and monospaced.

Here's a readable version: https://gist.github.com/mikemaccana/10847077

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

#48

Post by jacquesm »

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.

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.

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

#49

Post by jacquesm »

rkangel wrote: post #43
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…

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

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

#50

Post by VeejayRampay »

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.

Well tell him that's a great reaction to have in that situation. I find it mature and I wish more people would act that way.
Post reply on HN