enabling "none" cipher

[Ron Frederick]

On Feb 28, 2026 at 8:46:01 AM, Theo de Raadt <deraadt at openbsd.org> wrote:

> Alternatively, we can do none of this, and continue to maximally
> encrypt ALL phases of the SSH protocol.
>

While I understand why this was valuable in HPN-SSH once upon a time, I do
wonder if there’s as big a performance benefit now, with so many processors
now offering hardware-accelerated AES encryption. That said, according to
the FAQ, HPN-SSH also offers a multi-threaded AES-CTR option which performs
quite well, and a faster ChaCha20-Poly1305 implementation. I wonder if one
or both of those might be a better option for inclusion into mainstream
OpenSSH.

For those unfamiliar with this, check out
https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/.

Ron Frederick <ronf at timeheart.net> wrote:
>
> On Feb 24, 2026 at 12:59:47 AM, Stef Bon <stefbon at gmail.com> wrote:
>
>
> > I've written also SSH software, and as I see it the "none"
>
> > ciphers/hmac/compress algo is the algo used in the phase before new
>
> > keys are used (in the init phase).
>
> >
>
> > The send and receive functions are designed to use
>
> > ciphers/hmac/compress after they are initialized and setup to use the
>
> > new keys. These functions should be robust enough to use the "none"
>
> > cipher/hmac/compress algo's just like before the new keys are
>
> > determined.
>
> >
>
>
> From what I understand, it’s a bit more complicated than this, as the
>
> desire is to still encrypt the authentication phase of the SSH handshake
>
> and only switch to the null cipher and mac algorithms after auth completes
>
> successfully. To do this, there would need to be a way to negotiate
>
> algorithms and keys for use during auth, with an intent to turn these off
>
> once auth completes, and ideally to do so in a way that allows both sides
>
> to know the exact place in the byte stream to switch over.
>
>
> It might be possible to do something like this with re-keying, but I think
>
> there would be some amount of data which was encrypted at the beginning of
>
> the connection until the rekeying completed. This may be ok, but it’s not
>
> very clean. It would be better if you could negotiate up front whether to
>
> turn encryption off when auth completes.
>
>
> As for compression, you generally don’t want compression during auth (see
>
> https://www.openssh.org/txt/draft-miller-secsh-compression-delayed-00.txt
> for
>
> more details). The delayed compression mechanism in this draft provides a
>
> way to negotiate no compression, compression of all packets after NEWKEYS,
>
> or compression only after USERAUTH_SUCCESS. So, it probably doesn’t need to
>
> be part of this. It can be used as an example of what I mentioned above,
>
> though, where you negotiate ahead of time whether to switch, and know
>
> exactly when that should be done.
>
> --
Ron Frederick
ronf at timeheart.net