Optional 'test' or benchmark cipher

[Chris Rapier]

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. 

You should look at HPN-SSH at http://www.psc.edu/networking/projects/hpn-ssh

This implements the NONE cipher exactly as you describe with the caveat 
that it still generate HMACs. Authentication is fully encrypted and it 
then it switches to the NONE cipher. One important caveat is that you 
*cannot* use this NONE cipher in interactive sessions. Its only 
available for bulk data transfers.

HPN-SSH does implement a different way of handling the flow control 
window but you can disable that if you want something more similar to 
the default functionality of OpenSSH.

If you need any help with it or have any questions feel free to ask me 
since I wrote it.

> 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'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).
> 
> 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
> data.
> 
> (I'm sorta surprised a null algorithm hasn't already been
> made available, at least for testing during development.)
> 
> Hopefully it wouldn't be thought of as a security risk with
> the appropriate safeguards in place.

I do not believe this would ever be included in the main OpenSSH code as 
it does break some near explicit assumptions about SSH (though it 
doesn't violate the RFC).