What version of Go are you using (go version)?

go version go1.11.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/vadimyer/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/vadimyer/GoSpace"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ty/jl_43d0n2vjckpwsct7k3g3m0000gn/T/go-build709033229=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I've got an AP (ApplePay) tokens decryption library (really like all the rest existing in terms of algorithms). It is based on this library: https://github.com/processout/applepay with a few refactors for my app.

The library almost successfully works on production. The problem is, not every token gets decrypted. Sometimes there are tokens which (as far as I've known) for which the secret gets broken. Why and how broken?

Well, every single token gets decrypted without any errors with this library: https://github.com/sidimansourjs/applepay-token, but this is Node and JS. The byte representation of a derived secret in Node (for "bad" tokens) differs from that one in Go by 1 single byte in the beginning, which is sometimes a zero (0), in cases where the Go implementation can't decrypt an AP token. So when Go application can't decode a token, it's always missing a zero in the beginning of a secret, which leads my thoughts there's something wrong with deriving a secret, so probably a bug in elliptic or similar.

Note, that it doesn't really happen with every token, only like 1/20 of all tokens I get, and those which decrypt successfully by default, do not have a leading zero byte for their derived secret in both implementations.

What did you expect to see?

The same derived secret as in Node JS case, with a fully decrypted plaintext as a result.

What did you see instead?

The secret without a leading zero byte, leading to a failed decrypt result.