9 ms·

Practical Cryptography With Go

106 points by damian2000 13y ago

Jabbles 13y ago
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/crypto.go#L43 https://github.com/kisom/gocrypto/blob/master/chapter2/chat/...
- damian2000 13y ago
  But it works even though there's some redundant code ... maybe the author wanted to leave the original slice untouched?
- tptacek 13y ago
  Is that a chat protocol using unauthenticated AES? Is this an example of what _not_ to do?
  - ctz 13y ago
    It comes on to authenticated encryption later. https://github.com/kisom/gocrypto/blob/master/chapter5/authsym/authsym.go#L99 https://github.com/kisom/gocrypto/blob/master/chapter5/auths... This is the authenticate-then-decrypt-anyway pattern. 100% Vaudenay compliant.
    - tptacek 13y ago
      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 13y ago
        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 13y ago
        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).
  - mukyu 13y ago
    I particularly liked the distinct error on bad padding, because that could never go wrong with CBC.
jfolkins 13y ago
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
zura 13y ago
Anyone can comment if this Free to read online but paid PDF/EPUB download model works?
tptacek 13y ago
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/3cc34251e501c2c8ffb7/raw/cf9ff4e7ce13985458b240980e91202ac732b4e6/Practical+Cryptography+in+Go+ https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...)
- cryptonoob 13y ago
  Do you have any books that you can recommend as an alternative for learning cryptography (for people with some exposure/programming experience but not experts in crypto)?
  - tptacek 13y ago
    http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/ http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp... The more important recommendation, which this book misses, is NaCl (or its repackaging in libsodium). If you can use NaCl, use NaCl, and nothing else.
    - dchest 13y ago
      Speaking of Go, the official go.crypto repository comes with NaCl port: https://godoc.org/code.google.com/p/go.crypto/nacl https://godoc.org/code.google.com/p/go.crypto/nacl
    - yeukhon 13y ago
      How about Practical Cryptography (http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573 http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/...) as a quick-guide over the more verbose Applied Cryptography which is much older than the former?
      - tptacek 13y ago
cweagans 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
      - tptacek 13y ago
        Finding the cryptographer who answered your question the way I did is left as an exercise to the reader.
        deleted 13y ago
        [deleted]
      - m0nastic 13y ago
        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.

106 points by damian2000 13y ago

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/crypto.go#L43 https://github.com/kisom/gocrypto/blob/master/chapter2/chat/...

damian2000 13y ago
But it works even though there's some redundant code ... maybe the author wanted to leave the original slice untouched?
tptacek 13y ago
Is that a chat protocol using unauthenticated AES? Is this an example of what _not_ to do?
- ctz 13y ago
  It comes on to authenticated encryption later. https://github.com/kisom/gocrypto/blob/master/chapter5/authsym/authsym.go#L99 https://github.com/kisom/gocrypto/blob/master/chapter5/auths... This is the authenticate-then-decrypt-anyway pattern. 100% Vaudenay compliant.
  - tptacek 13y ago
    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 13y ago
      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 13y ago
        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).
- mukyu 13y ago
  I particularly liked the distinct error on bad padding, because that could never go wrong with CBC.

jfolkins 13y ago

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

zura 13y ago

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

tptacek 13y ago

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/3cc34251e501c2c8ffb7/raw/cf9ff4e7ce13985458b240980e91202ac732b4e6/Practical+Cryptography+in+Go+ https://gist.githubusercontent.com/anonymous/3cc34251e501c2c...)

cryptonoob 13y ago
Do you have any books that you can recommend as an alternative for learning cryptography (for people with some exposure/programming experience but not experts in crypto)?
- tptacek 13y ago
  http://sockpuppet.org/blog/2013/07/22/applied-practical-cryptography/ http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp... The more important recommendation, which this book misses, is NaCl (or its repackaging in libsodium). If you can use NaCl, use NaCl, and nothing else.
  - dchest 13y ago
    Speaking of Go, the official go.crypto repository comes with NaCl port: https://godoc.org/code.google.com/p/go.crypto/nacl https://godoc.org/code.google.com/p/go.crypto/nacl
  - yeukhon 13y ago
    How about Practical Cryptography (http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573 http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/...) as a quick-guide over the more verbose Applied Cryptography which is much older than the former?
    - tptacek 13y ago

cweagans 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.
    - tptacek 13y ago
      Finding the cryptographer who answered your question the way I did is left as an exercise to the reader.
      - deleted 13y ago
        [deleted]
    - m0nastic 13y ago
      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.