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. 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. Linda Walsh
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).
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 server side.> > 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 > data. > > (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 work.> > 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. -- Iain Morgan