I am a maintainer of a Go package which provides access to keys held in PKCS#11 HSMs to Go programs, using (as far as possible) native Go crypto APIs.

For asymmetric keys, this was a pleasant experience. It was straightforward to expose ECDSA keys via crypto.Signer. The interface was obviously designed with HSMs in mind (and we appreciate the thought l-)

Currently I am adding support for symmetric keys. This can be made to work but certain operations are very slow, due to a mismatch between the PKCS#11 API and the Go crypto/cipher APIs.

Specifically, to efficiently perform 'bulk' crypto operations, the PKCS#11 API requires a sequence of three calls:

1. C_EncryptInit
2. C_EncryptUpdate (any number of times)
3. C_EncryptFinal

Even if the mode in question does not produce any ciphertext in the call to C_EncryptFinal, it is necessary to call it in order to release resources.

However, cipher.Block and cipher.BlockMode provide no way for the caller to signal that they are finished. Essentially they lack a Close method. So an implementation of either of these interfaces that uses an HSM is not possible.

It is possible, of course, for a cipher.Block to encrypt a single block and clean up after itself (and this is what I've done). However using such an implementation from cipher.NewCBCEncrypter can be hundreds of times slower than an idiomatic PKCS#11-aware implementation.

My questions/requests in this issue are:

1. Is there any possibility of adding Close() methods to the existing cipher.Block and cipher.BlockMode interfaces?
2. Failing that is there any way for an implementation to detect that its object is no longer referenced and the underlying resources can be released? i.e. something analogous to, or attacking the same problem as, a C# finalizer?

See ThalesGroup/crypto11#6 for additional information, although I believe I've captured everything relevant above.

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

go version go1.10.3 linux/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="/home/rjk/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/rjk/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build914934708=/tmp/go-build -gno-record-gcc-switches"