enabling "none" cipher

[Chris Rapier]

On 2/27/26 20:35, Ron Frederick wrote:

> 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.

Yes, that's what we do in HPN-SSH. I'm the lead dev on that. The NONE 
cipher switch was developed by Michael Stevens (one of my undergrad 
interns) after he noticed that you could force a rekey at any point 
during a connection using the control characters.

> 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.

Nope, the rekeying happens immediately after the auth process completes. 
Basically, we negotiate the auth process with the chosen public key 
algorithm and whatever the default private key algo might be. This 
negotiated provate key algo is not actually used at any point because we 
immediately rekey to NONE after auth but before any data is sent. It 
would be somewhat cleaner, conceptually, if we negotiated NONE during 
the initial process but it really doesn't make a difference overall. 
Doing it this way is also less intrusive in terms of the merging with 
OpenSSH.

Now, on one level I disagree with Theo about supporting smaller 
communities because sometimes these small communities are not that small 
That said, OpenSSH has a vastly larger user base across a much wider 
range of platforms and use cases. HPN-SSH also isn't a core pillar of 
expected functionality that is essentially ubiquitous across most every 
platform. We serve people we specific needs and goals in terms of bulk 
data transport. That's not the same mission as OpenSSH and I fully 
respect the incredible work that the OpenSSH dev team does day in and 
day out. They are able to do that great work by focusing clearly on 
their mission and their priorities. Incorporating NONE cipher as a 
transport encryption method is simply outside of that focus.

Anyway, from what we can tell not many people actually use the NONE 
cipher because the performance benefits, while notable (8-9Gbps vs 7Gbps 
for GCM), aren't as compelling as they used to be. When the transfer 
process was largely limited by the overhead imposed by the encryption 
process the NONE cipher made a lot more sense for transferring public 
data sets. With modern processors with AESNI and significantly more 
processing power it's just not as important as it once was. There are 
other bottlenecks in the main thread that we (HPN-SSH) are more focused 
on. We'll continue to support NONE and, maybe, after we resolve some of 
these other bottlenecks, it will once again be 2x or 3x faster that an 
encrypted method but, until then, it's just not as compelling, from a 
performance perspective, as it once was.

Chris