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