
Practical Cryptography With Go - damian2000
https://leanpub.com/gocrypto
======
tptacek
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:

[http://pastebin.com/raw.php?i=NXgU30xK](http://pastebin.com/raw.php?i=NXgU30xK)

(as a Github gist:

[https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...](https://gist.githubusercontent.com/anonymous/3cc34251e501c2c8ffb7/raw/cf9ff4e7ce13985458b240980e91202ac732b4e6/Practical+Cryptography+in+Go+))

~~~
bachback
thanks. but why has crypto to be equivalent to "heart surgery"? if I would
describe the state of the art of Internet security I wouldn't apply that term.

~~~
tptacek
The point isn't about life and death so much as it is about the likelihood of
success for someone just starting out with only a book as a guide.

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

In response to Jabbles, this is from his (work in progress) book. Page 7.

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

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.

I personally have purchased this book as well as reported errors to Kyle.

I'd encourage anyone with questions or comments to reach out to Kyle. He is
quick to respond.

[http://www.kyleisom.net](http://www.kyleisom.net)

------
Jabbles
I can't comment on the author's cryptographic knowledge, but his Go seems non-
idiomatic, and in some cases plain weird.

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.

[https://github.com/kisom/gocrypto/blob/master/chapter2/chat/...](https://github.com/kisom/gocrypto/blob/master/chapter2/chat/crypto.go#L43)

~~~
tptacek
Is that a chat protocol using unauthenticated AES?

Is this an example of what _not_ to do?

~~~
ctz
It comes on to authenticated encryption later.

[https://github.com/kisom/gocrypto/blob/master/chapter5/auths...](https://github.com/kisom/gocrypto/blob/master/chapter5/authsym/authsym.go#L99)

This is the authenticate-then-decrypt-anyway pattern. 100% Vaudenay compliant.

~~~
tptacek
That is _not_ "100% Vaudenay compliant".

It happens that in this library, with padding errors delivered as error return
values, checking a MAC and then obliviously decrypting won't leak the broken
pad values --- presuming your code (a) uses the author's idiosyncratic 80h+00h
padding scheme, or (b) uses PKCS7 padding like every other system _and_
carefully checks to make sure that the pad bytes don't run it off the end of a
slice --- doesn't fatally compromise the security of the system.

But in virtually every other language in which people implement cryptography,
the pattern the author uses snatches defeat from the jaws of victory by
creating the opportunity for padding exceptions even after the code has
verified for itself that the message it's decrypting can't possibly be valid.

Obviously, the bigger problem is that you're more than halfway through the
book before you find out that the example from Chapter 2 is totally hosed.

~~~
ctz
You're right, and it's by-the-by; I missed that decrypt() had moved on to CTR
in that code.

If it had been CBC with ISO7816 or PKCS#5 padding then I do think this would
be attackable. The unpadding errors from decrypt trump the MAC error thanks to
the "err == nil && !match" expression.

~~~
tptacek
Fortunately, it's not giving a distinctive error, and always runs both the MAC
and the decryption so timing won't distinguish, either. The big problem with
this pattern is how disastrous it is in every other language (coupled with the
lack of any rationale for decrypting on MAC failure).

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

~~~
coldtea
So where do expert cryptographers come from if they aren't allowed to start
and write their own stuff at some point?

They start as complete masters of the field in their teenage years?

~~~
tptacek
They start by learning to break other systems. That's not my suggestion; it's
from a well-known cryptographer people on HN seem to like a lot.

~~~
coldtea
Hmm? This sounds like its describing a hacker ("cracker"), not a
cryptographer.

One could know all about buffer overflows, memory layout arcana and whatever,
but not actually now much about cryptography, primes, et al.

~~~
m0nastic
Breaking crypto systems isn't the same as breaking "into" systems.

The history of cryptography can basically be described as a series of
assumptions which turn out to be invalid. This is either because they were
never valid to begin with (and it just took time for problems to be discovered
and shaken out), or because the facts on the ground change, making them
invalid.

I'm not a cryptographer. I also don't really call myself a hacker anymore
(because the loaded assumptions around that word make it useless as a
descriptor, you wind up having to explain it in so much detail that it's just
easier to start out with a different word), but I do know some cryptographers.
They have all described the process in a similar way, which is you start by
learning about the pitfalls of everything that's come before you.

Much like if you were learning to build bridges, you'd spend time learning
about past bridges that didn't hold up.

So you start with the oldest crypto systems, and learn why those fell out of
fashion. One nice benefit to this approach is that it makes it fairly apparent
how brittle these constructions are. I don't think I've ever met a
cryptographer who isn't suitably hesitant about designing cryptographic
systems. Also, a good portion of the time spent as a cryptographer (maybe most
of it? I'd love to hear a dissenting view from an actual cryptographer), is in
breaking cryptographic systems (initially other people's, and than later, your
own).

Cryptography isn't like web frameworks in the sense that everyone is making
their own. New crypto systems (at least ones that come from cryptographers)
don't spring up out of the ether every week.

One problem that seems to come up in cryptography is that cryptographers
themselves "seem" to be mostly only concerned with the primitives. They leave
implementation as "an exercise to the reader". This is a problem because I'd
say that the overwhelming majority of actual security problems that stem from
cryptography aren't problems with the primitives. They're problems with the
construction necessary to do anything useful with those primitives. That's why
when people heed advice like "Use AES" they're probably screwed.

~~~
pbsd
You're pretty much on point. When designing a scheme, whether a low-level
cipher or a higher-level protocol, only a small fraction of the time is spent
on the initial design itself. That is not to say that a scheme is designed and
promptly finalized; analysis results feed back into the design process, of
course. But the analysis is generally by far the most time-consuming task.

Additionally, sane people do not use building blocks that they don't trust. If
you need a block cipher you use AES (which is partially backed by security
proofs) instead of designing your own (unless you have very specific
requirements). This saves immense time in both design and analysis. Same with
modes (Feistel structure, Sponges, HMAC, etc). Proofs play a big role here,
although it is important to understand what they say, instead of blindingly
assume they mean whatever you use them for is secure.

You are right that implementation is generally left as an afterthought. This
is slowly changing, and primitives are increasingly being designed for
implementation and side-channel friendliness.

------
zura
Anyone can comment if this Free to read online but paid PDF/EPUB download
model works?

