Re: Optional 'test' or benchmark cipher

Iain Morgan wrote:
>
> As Chris Rapier has pointed out, the HPN-SSH patch adds this capability.
> I don't know if the HPN-SSH patch supports that functionaliy on the
> server side.
----
Sounds like it is unlikely to provide an "easy" way to remove
the data encryption from the equation.

I'm not clear if the HPN-SSH "patch" is a patch over Ossh or
a different, but depending on how much change HPN-SSH adds, I might
be benchmarking something that is unrepresentative of Ossh.


> What are you typically seeing for your transfer rates? What cipher/MAC
> combination are you using and what version of OpenSSL? Also, what
> version of OpenSSH?
----
Most are under 12MB/s (which, I know, sounds like very good
100Mbs performance -- cept that I'm expecting Gigabit performance.

Interfaces are running at 1G verified w/"ethtool" and "lights on
the switches involved".

I looped through all of the ciphers transferring a 256MB
uncompressible (bzip2'ed) file (No compression enabled on any machine, BTW). The fastest cipher was the first tried (default) aes128-cbc. Most were
significantly slower (~3-10X). But the fastest was 16.7MB/s, with
the rest under 11.9 (and one ~1.1MB (unexplained slowness between 2 fastest
machines). The win machine has 3-switches between it and the other 3 --
they are all off the same switch.

> Why add a potential security hole merely for the sake of testing? I
> would think you'd want to test ssh the way it is actually intended to
> work.
----
I want to test it both ways. How can I easily tell what is due to
my network's speed, the SSH protocol, or even the implementation?
How is it a security hole? I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only
something someone would use with certain "safe" (likely internal-private)
networks. Also, in order to make certain it comes from a valid machine,
session authentication should be done "as normal". Only after
authentication would null be allowed.

For safety on the client, I'm fine with using a 3-factor enabling
protocol:
1) enabled/disabled in sitewide ssh_config
2) enabled in user's config, and
3) specify its use on the ssh (or scp) command line with a
"--no-data-encrypt" flag.

That should spell it out very clearly enough to prevent
"accidents". What security holes would I be missing?

I can see this not being used just for testing, but also for
sending pre-encrypted files -- why encrypt them again?

> The topic of adding a NONE cipher has comes up on this list from time to
> time. Each time it has been shot down - for good reasons in my opinion.
---
The linux kernel includes some non-encrypting ciphers that can
be compiled in -- a null cipher and a compressing cipher if memory serves.
No one has ever indicated it to be a security hole. Perhaps they are
not identical situations, but there is precedence, of a sort.

Hardware setup and more detail available if desired.

Linda
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev