Optional 'test' or benchmark cipher

Chris Rapier rapier at psc.edu
Thu Jan 17 06:45:19 EST 2008



Iain Morgan wrote:

> I don't know if the HPN-SSH patch supports that functionaliy on the
> server side. 

Ya know, I never thought about it. My feeling was always that if a 
server wanted to support it then they'd support it and leave it up to 
the users to decide if they wanted to make use of it. I'll look into 
this more when I get back from some conferences I'm going to.

Speaking of which, if anyone here is goign to the APAN/Joint Techs 
meeting in Hawaii or the Mardi Gras '08 conferences I'll be presenting 
on this work.

> 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?

Its important to realize that a number of factors go in to throughput 
and the bottleneck might not be where you think it is. This is why I 
usually start by benchmarking things with some sort of lightweight test 
like Iperf. You can even use it with a sample data file to see how your 
disk I/O is impacting performance. At that point you tune the system to 
maximize Iperf performance. Then you start with the SSH tests to get a 
better idea of the overhead imposed.

> 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.

Well... NONE *is* part of the protocol in that its not explicitly banned 
(its a 'should not' instead of a 'must not'). Under the right 
circumstances and implementation it doesn't, in my view, impose an 
unacceptable risk. Even so, use of NONE is a very effective way to 
determine where internal application bottlenecks might lie.

> 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.

Applications like GridFTP provide secure authentication but don't 
encrypt or do message authentication on the bulk data. While I'm not a 
huge fan of GridFTP I don't find any fault in their decision to take 
this route.


More information about the openssh-unix-dev mailing list