Re: Optional 'test' or benchmark cipher

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev