/cc @FiloSottile @rolandshoemaker @golang/security

It sounds like this is essentially a proposal to add a new API, say NewOpenSSH, which returns a cipher.AEAD that uses a 16 byte nonce.

Given it's no worse than the standard (smaller) nonce size, and it provides support for a deployed construction (OpenSSH choosing the middle of the road size between standard and X was a fun choice), I have no real opposition.

Can someone write down the proposed new API with its doc comment? Thanks.

Probably this:

// NonceSizeOpenSSH is the size of the nonce used with the chacha20poly1305@openssh.com variant of this
// AEAD, in bytes
NonceSizeOpenSSH = 16

// NewOpenSSH returns a chacha20poly1305@openssh.com AEAD that uses the given 256-bit key.
//
// chacha20poly1305@openssh.com is a ChaCha20-Poly1305 variant that uses a non-standard nonce size,
// suitable for usage with OpenSSH.
func NewOpenSSH(key []byte) (cipher.AEAD, error)

I also need this. My workaround is to copy the source into my personal ssh module, which is a sub-optimal outcome. Indeed poly1305 is a footgun, but as used by ssh it is ok. For the crypto library to hide it entirely, preventing independent implementation of ssh, seems peculiar.

Are we talking about the same nonce? I allocate a 12-byte nonce and for OpenSSH compatibility use a 4-byte packet counter and zero-fill.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It sounds like there are few enough of these variants that we should add them all explicitly instead of exposing primitives like poly1305 and leaving people to connect them correctly. #57699 (comment) seems fine except that we need to resolve whether we're talking about two different variants, or maybe three (nonce lengths 12, 16, 24).

/cc @FiloSottile

The existence of an "original" variant of ChaCha20Poly1305 and an IETF variant is unfortunate, but nearly everything and everyone converged on the IETF variant, and I wouldn't want to contribute to rekindling that mess.

Besides, my understanding is that the "original" variant has a 8 bytes (64 bit) nonce, not a 16 bytes nonce. https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.chacha20poly1305 and https://github.com/golang/crypto/blob/9e92970a1eb41e446822e037016aa89d24c0ce7a/ssh/cipher.go#L669 seems to agree with that. Where is the 16 bytes nonce size coming from?

Taking a step back, why do you need to use this variant of the AEAD directly? You mention generating encrypted OpenSSH keypairs, maybe we should just extend the ssh.MarshalPrivateKeyWithPassphrase API, maybe as part of #68723 which is already adding a struct for marshal parameters?

Finally, x/crypto/poly1305 is Deprecated, not removed, so it's not the case that it is no longer possible to use it. If you know what you are doing enough to want to use a non-standard AEAD to do low-level operations on an encrypted key, using a deprecated package doesn't sound wrong.

Yes, I was also puzzled about the OP comment about 16 byte nonce. Perhaps he can clarify.

I may have misunderstood your proposal with respect to marking deprecated versus moving to internal. As long as crypto/ssh/cipher.go interoperates with OpenSSH and does not import crypto/internal then fine.

As long as crypto/ssh/cipher.go interoperates with OpenSSH and does not import crypto/internal then fine.

x/crypto/ssh may move to the standard library, at which point who knows what it will import. My point is that your ssh module can keep importing x/crypto/poly1305 even if it is deprecated.

I withdraw my request. For ssh, I'll revert to aes-gcm. For other contexts, if aes is too heavyweight, I'll select ascon80pq.

My understanding is that, while x/crypto/poly1305 is deprecated (owing to the potential for misusing the API), it's still usable as part of the implementation of the ssh protocol if needed. Since it sounds like this proposal isn't needed, I'm going to move it toward decline.

Based on the discussion above, this proposal seems like a likely decline.
— aclements for the proposal review group

No change in consensus, so declined.
— aclements for the proposal review group