I am not a fan of this book. I wrote a review of the book as an HN comment. I dislike this book so much that for the first time in the history of my use of HN, my comment overflowed the bounds for HN comments. So, here it is:<p><a href="http://pastebin.com/raw.php?i=NXgU30xK" rel="nofollow">http://pastebin.com/raw.php?i=NXgU30xK</a><p>(as a Github gist:<p><a href="https://gist.githubusercontent.com/anonymous/3cc34251e501c2c8ffb7/raw/cf9ff4e7ce13985458b240980e91202ac732b4e6/Practical+Cryptography+in+Go+" rel="nofollow">https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...</a>)
I know Kyle personally. He is super smart, incredibly humble, and willing to teach. And I always admire anyone taking the initiative to try and produce something useful.<p>In response to Jabbles, this is from his (work in progress) book. Page 7.<p><pre><code> // Implement the standard padding scheme for block ciphers. This
// scheme uses 0x80 as the first non-NULL padding byte, and 0x00 to
// pad out the data to a multiple of the block length as required.
// If the message is a multiple of the block size, add a full block
// of padding. Note that the message is copied, and the original
// isn't touched.
</code></pre>
As anyone who has written technical material knows, your drafts tend to be error prone and you rely heavily on others to help catch your mistakes. Technical editors are the normal tool utilized by the traditional publishing world. As this is a leanpub book, I feel that the responsibility generally falls on the community. Those who have paid for the book and want to see it succeed.<p>I personally have purchased this book as well as reported errors to Kyle.<p>I'd encourage anyone with questions or comments to reach out to Kyle. He is quick to respond.<p><a href="http://www.kyleisom.net" rel="nofollow">http://www.kyleisom.net</a>
I can't comment on the author's cryptographic knowledge, but his Go seems non-idiomatic, and in some cases plain weird.<p>For example, this function stores the length of a slice in a variable, creates a new slice of the same length, copies all the bytes from the old to the new, then checks that the length of the new one is the same as the old (stored variable) - since it cannot have changed this check never fails. Hardly inspires confidence.<p><a href="https://github.com/kisom/gocrypto/blob/master/chapter2/chat/crypto.go#L43" rel="nofollow">https://github.com/kisom/gocrypto/blob/master/chapter2/chat/...</a>
Books like this scare the hell out of me. People can't even seem to use tried-and-true crypto libraries without screwing something up most of the time. Now you want them to write their own? This sounds like an absolute disaster waiting to happen.