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

11–20 of 255 posts

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

#11

Post by eproxus »

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 quickly familiarize themselves with the material (and might even help a few understand more than they would have done without expanded abbreviations).

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

#12

Post by austinz »

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 rigorous testing and analysis from first principles to try and isolate potential weaknesses. In all cases you want to ensure the people who worked on the system knew what they were doing and put the right amount of due diligence into ensuring the system works correctly.

Unfortunately, not even widely used, highly trusted implementations work right all the time. A out-of-bounds memory bug introduced by an insufficiently vetted commit opened up a serious flaw in OpenSSL. On a much, much smaller scale, I once had the misfortune of working with an old version of Microchip's PIC18 AES library, which had some serious issues that made it nonfunctional for anything more complex than the toy sample app it shipped with. But with enough exposure these problems are eventually exposed and fixed. Would a world where everyone rolled their own bespoke, ad-hoc SSL implementations be more secure? I doubt it.

In the end, I think there needs to be a cultural shift. People shouldn't be discouraged from building their own crypto for fun and learning, but they should be discouraged from deploying it for any application where real security is required - at least not before undergoing rigorous analysis. One of the first things Dan Boneh teaches in his Crypto I class is that you should think very long and hard before implementing your own cryptosystems (i.e. don't do it), because getting it right is hard, and getting it even the slightest bit wrong tends to make it useless. And when you consider that people's livelihoods (their personal information, their money) and even lives might be jeopardized, taking responsibility as an engineer becomes of paramount importance. Crypto just doesn't lend itself to a "build an MVP, get it working, move fast and break things" mindset.

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

#13

Post by dfc »

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…

Welcome to HN. I see that you are new here so I would like to give you a little friendly advice. If you have to make a long list like this on HN use the pre/code formatting (two spaces at begining of line). Long lists like this take up a ton of space. I have a sneaking suspicion this is the a deliberate design choice so that people link to reference resources and use the comments for discussion. Compare:

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

  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

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

#17

Post by duongkai »

laichzeit0 wrote: post #14

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.

Let check the profile of tptacek. In his profile, there is a his reading list. Grab some book about cryptography.

Or you can browse his blog, Practical Cryptography or Cryptography Engineering may be a good start.

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

#18

Post by lkozma »

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…

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.

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

#19

Post by GuiA »

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 experience to see where they fall short, the industry know-how, and so on.

I feel like instances of this in the tech community are not too rare, and it's a consequence of the internet: anyone can publish a book and distribute it all over the world now. It's worth keeping in mind that while harm is being done through the spread of false information, what's most important is to educate them, see this as a teachable moment, so they can become productive experts and modify their message to be fully correct. Of course, it requires them to be open minded of their shortcomings: but it can be done.

PS: I have no clue who the author of Practical Cryptography With Go is.

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

#20

Post by gojomo »

Brutal but also in some ways a gift to the author/publisher. Paired with the 1st edition, it cures the major defects.

And, if the criticisms can be addressed, in both specifics and perspective, for a future edition, they'll have a hardened book... almost sure to earn another updated expert review ("is it fixed?") at that time.

Post reply on HN