enabling "none" cipher

[Theo de Raadt]

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



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