enabling "none" cipher

[Chris Rapier]

On 1/12/26 20:01, Nacho wrote:
>> Hey there, that's part of my HPN-SSH patch set.
> 
> Just a short question: if I have the patch compiled in and do "ssh -Q cipher" I
> should see "none" as a cipher option? (I don't)

Nope. I need to remember why I made that decision as it was many years 
ago. What we do is essentially replace the entire cipher list with a 
single entry of 'none' when it's requested as we don't want it to 
fallback to another encryption method. Anyway, from the debug statements 
you will see:

debug1: REQUESTED ENC.NAME is 'none'
debug1: REQUESTED MAC.NAME is 'umac-64-etm at openssh.com'
debug1: None requested post authentication.
debug1: kex: server->client cipher: none MAC: umac-64-etm at openssh.com 
compression: none
debug1: REQUESTED ENC.NAME is 'none'
debug1: REQUESTED MAC.NAME is 'umac-64-etm at openssh.com'
debug1: None requested post authentication.
debug1: kex: client->server cipher: none MAC: umac-64-etm at openssh.com 
compression: none


>> All that being said, I don't maintain the FreeBSD patch so I don't know what
> 
> The FreeBSD patch didn't work for me, but didn't have time to look into it,
> 
> I'm compiling it for armv6, that could make a difference?

I know at one point we were doing test builds on armv6 but that was 
quite some time ago. As such I can't explicitly say that should or 
shouldn't work. I'd need to get access to a armv6 platform to test that. 
I might have one somewhere but I'll need to dig it out.

> 
>> doing. That is available from https://github.com/rapier1/hpn-ssh/ if you
>> feel like trying to build it from source.
>   
> In that repo I just see the whole openssh source tree already modified.
> 
> Do you mantain a .patch file I could apply to the current openssh source?

No, but if you are familiar with git a "git diff" will generate one 
pretty easily. If not let me know the specific version of openssh you 
want to patch against. Also, the git repo builds binaries that are 
prefixed with "hpn". You'll end up with hpnssh and hpnsftp instead of 
ssh and sftp.

> 
>> One last thing: The none cipher is really only useful when you know the
>> session is being CPU limited due to encryption. If you aren't pushing
>> multiple Gbps it's unlikely that's the case on more modern processors. It's
> 
> Yes, I understand that, have been working with ssh daily for the last 27 years.
> 
> The problem here is a slow CPU in an embedded system, and this is connected to a
> server in an isolated wired network, it's perfectly safe not to use encription
> for data in this use case.

Absolutely makes sense in this scenario and it sounds like you are being 
CPU limited. The next step would to make use of the nonemac switch as 
well. That disables the MAC - which is effective as long as you trust 
the TCP layer CRC to catch bit errors on the network.