Optional 'test' or benchmark cipher
open-ssh at tlinx.org
Thu Jan 17 12:47:02 EST 2008
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
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
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
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.
More information about the openssh-unix-dev