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

$ go version
go version go1.21.3 darwin/arm64

Does this issue reproduce with the latest release?

Yes

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

$ go env
...
GOARCH='arm64'
GOOS='darwin'
...

What did you do?

golang.org/x/crypto 0.4.0 introduced a breaking API change in the AddASN1Int64() method.
Previously, reflection was used to determine the underlying type of the provided out argument.
As of golang/crypto@2c47667 - it instead uses type assertions.

This is a breaking change - while previously one could pass named types whose underlying types are integers,
that same code as of x/crypto >=0.4.0 will panic.

Reproduction:

https://go.dev/play/p/1__wSXq30mR

...

package main

import (
	"testing"

	"golang.org/x/crypto/cryptobyte"
)

type MyInt int64

func Test_ReadASN1Int64(t *testing.T) {
	const expectedVal = 1234

	b := cryptobyte.NewBuilder(nil)
	b.AddASN1Int64(expectedVal)
	buf, err := b.Bytes()
	if err != nil {
		t.Fatalf("failed serializing to buffer: %v", err)
	}

	var out MyInt // underlying type is int64

	t.Logf("deserializing type: %T", out)
	input := cryptobyte.String(buf)
	if !input.ReadASN1Integer(&out) {
		t.Errorf("deserializing integer failed")
	}
}

What did you expect to see?

I expected code similar to the reproduction above to continue functioning with newer versions of x/crypto.
If this was not feasible, I would have at a minimum expected a release note describing the breaking change,
or to see it reflected in semantic versioning of the library.

What did you see instead?

Working code began to panic upon upgrading x/crypto >= 0.4.0.