enabling "none" cipher

[Theo de Raadt]

Once again you are focusing on priorities which are preferred by minor
sub-community.

The major community wants cryptographically backed security WITH PRIORITY
ABOVE ALL OTHER CONCERNS.

We did not do threads, because the original code did not do threads.
Even today, I think the concerns over threads in a security focused piece
of software are not irrelevant.

Let me guess, you also want a pony.

> 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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev