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

$ go version
go version go1.19.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/[REDACTED]/.cache/go-build"
GOENV="/home/[REDACTED]/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/opt/dev/go/pkg/mod"
GONOPROXY="[REDACTED]"
GONOSUMDB="[REDACTED]"
GOOS="linux"
GOPATH="/opt/dev/go"
GOPRIVATE="[REDACTED]"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1148312864=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This isn't so much what I did, but rather something the x/crypto team did. Understandably so, but nonetheless limiting.

With the implementation of #36646, it is now no longer possible to generate and modify chacha20poly1305@openssh.com-encrypted OpenSSH keypairs in a low/direct manner. (AES-encrypted keys are, of course, quite easy to modify and generate as long as the new key structure is understood.)

That is, one cannot create chacha20poly1305-encrypted OpenSSH private keys without vendoring/modifying ChaCha20 and Poly1305. Which then means they are highly susceptible to be not kept in-line with upstream (x/crypto)'s implementation, thus defeating a part of the intention of removing the public components in the first place as outlined in the original discussion.

What did you expect to see?

I expect to see an ability to use a cipher.AEAD with chacha20poly1305@openssh.com (which uses a 16-byte nonce for ChaCha20 instead of a 12 or 24-byte nonce).

What did you see instead?

This functionality is not possible without vendoring or maintaining a separate fork of, at the least:

• x/crypto/chacha20
• x/crypto/poly1305
• x/crypto/internal/poly1305 (unless implemented in fork of the above directly)

Add'l Notes (EDIT)

I received an email notification that someone commented inquiring if (golang.org/x/crypto/chacha20poly1305).New can be used but it appears it has been removed as it seems they understood the issue after commenting. :)

To avoid others making the same mistake, no, chacha20poly1305.New cannot be used because it uses a 12-byte nonce (and uses the RFC-specified padding), both of which are incompatible with the OpenSSH variant. Likewise, chacha20poly1305.NewX cannot be used because it uses a 24-byte nonce (and the RFC-specified padding), which also is incompatible with the OpenSSH variant. OpenSSH implements a 16-byte nonce and a "proprietary" padding mechanism using sequential uint8 integers. This is why their cipher implementation is named chacha20poly1305@openssh.com instead of chacha20poly1305.

For more information/technical details:

• https://datatracker.ietf.org/doc/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00
• https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305
• https://github.com/openssh/openssh-portable/blob/4a5590a5ee47b7dfd49773e9fdba48ad3089fe64/cipher.c#L106-L107 (struct defined here )
• https://github.com/openssh/openssh-portable/blob/master/sshkey.c