enabling "none" cipher

[Ron Frederick]

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