This is a discussion on Re: Optional 'test' or benchmark cipher - openssh ; On Tue, Jan 15, 2008 at 19:46:34 -0800, Linda Walsh wrote: > I hope this is the right list, as I'm desiring a feature addition > in openssh. I would like the option to have a 'null' cipher (after > ...
On Tue, Jan 15, 2008 at 19:46:34 -0800, Linda Walsh wrote:
> I hope this is the right list, as I'm desiring a feature addition
> in openssh. I would like the option to have a 'null' cipher (after
> the initial authorization, similar to 'delayed' for compression).
> It would have to be enabled on both client and server and server
> would never use it unless it was both enabled and asked for by
> the client.
As Chris Rapier has pointed out, the HPN-SSH patch adds this capability.
> I'd strongly prefer it be able to be enabled on a per-host
> basis on both client and server rather than a global (that may
> be the default way to treat all ciphers, but not sure).
I don't know if the HPN-SSH patch supports that functionaliy on the
> I'd like to use it primarily for internal benchmarks, though
> I suppose if the password is encrypted, one might be able to
> transfer non-sensitive or pre-encrypted data over the larger
> net. Virtually all of my machines seem to be cpu bound (even
> though 1 pair of newer machines shouldn't be; Not quite sure
> why I'm not getting more throughput there (yet).
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?
> Anyway -- being able to "drop" the encryption entirely and
> use a straight-through connection for the data (emphasizing
> that I'd prefer not sending cleartext passwords). Keeping
> the password encrypted allows wider usage across the
> internet of pre-encrypted or non-sensitive, compressed
> (I'm sorta surprised a null algorithm hasn't already been
> made available, at least for testing during development.)
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
> Hopefully it wouldn't be thought of as a security risk with
> the appropriate safeguards in place.
> Linda Walsh
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.
openssh-unix-dev mailing list