Mailing List Archive

On Fri, Jan 14, 2000 at 03:58:47PM +0100, Oliver M . Bolzer wrote:
> Hallo to everyone!
> First I would like to thank everybody for making a free implementation
> of ssh available.

> I am administrating the network at the computer science department of
> the University of Munich. Here, rcp (as in many other places, I guess)
> is banned for security reasons. I, aswell as others, use scp regulary
> to copy files from one machine to another.
> The problem is, that the transfer rate is nowhere near what an 100Mbps
> connection would give. To and from my P5-233 laptop gets only about
> 350KBps. Between P6-450 machines the performance is about double. In contrast
> if I used ftp, I'd get much much more. I checked and noticed, that ssh
> used up all the CPU power for encrypting the data.

If you are concerned with performance, I'd suggest using "des". You are
getting "trivial" encryption; i.e. not enough encryption to stop someone
from seeing the data given some time, but sufficient encryption to keep
"most" people from becoming the man in the middle and changing your data
in-transit. Even so, do NOT pass ANY sensitive data over des, since it
can be easily cracked within a couple of weeks.

> I remember ssh-nonfree having a cipher 'none' which does not encrypt
> the actual data. But it's not available in OpenSSH up to 1.2.1pre25 .
> I checked the source and all the infrastructure seemed to be there, so
> I added support for "-c none". See the attached patch.
> It has been tested between two up-todate Debian Linux (potato) boxes
> runngin Linux 2.2.13 and Linux 2.3.32 with openssh-1.2.1pre25.
> On the above said laptop transfer rates of 3MBps was obtained (loopback
> test)
>
> Because authentication is still done using RSA keys, there should be
> no huge security impacts. Also "-c none" would only be explictly specified
> by the user when transfering large files.

-c none is still a large security exposure. It is the encryption that keeps
someone from waiting until after keys pass and then immediately step in and
either alter data or intercept passwords.

I'm not even sure that I'd support this, but the only way this should go
into the tree is with a "--with-none" option for configure that is by default
"without".

David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard

It's been suggested to me that I use blowfish if I am more concerned
with speed than with security.

Wasn't there some weakness in the SSH protocol if the null cipher were
supported in the endpoints even if the user doesn't choose it? It may
have been a vulnerability to a man-in-the-middle attack, I'm not sure.

Phil

On Fri, 14 Jan 2000, Phil Karn wrote:

> Wasn't there some weakness in the SSH protocol if the null cipher were
> supported in the endpoints even if the user doesn't choose it? It may
> have been a vulnerability to a man-in-the-middle attack, I'm not sure.

yes - markus friedl (OpenSSH developer) reported this to BUGTRAQ in early
OpenSSH development. doesn't affect OpenSSH (or the OpenBSD third-party
/usr/ports/security/ssh port either)...

-d.

---
http://www.monkey.org/~dugsong/

On Fri, Jan 14, 2000 at 11:28:52AM -0500, David Rankin <drankin@bohemians.lexington.ky.us> wrote...

> > if I used ftp, I'd get much much more. I checked and noticed, that ssh
> > used up all the CPU power for encrypting the data.
>
> If you are concerned with performance, I'd suggest using "des". You are
> getting "trivial" encryption; i.e. not enough encryption to stop someone

des "is no longer supported in ssh"(man 1 ssh). Someone else suggested using
blowfish so I did some benchmarks. I copied a 23083KB file using scp on a
P5-233/64MB RAM laptop running Debian Linux (potato as of 1/13) with
Linux 2.3.32 three times using the various ciphers and calculated the average.
The command line used was
time scp -c XXX 07_Beethoven_Symph9Mov4.mp3 localhost:
where XXX is the cipher. For comparison I also copied using /bin/cp because
the experiment was done copying onto the same disk.

cipher time throughput
3des 1m43s 224KBps
blowfish 31s 769KBps
none 17s 1357KBps
/bin/cp 13s 1776KBps

none still has a 2:1 speed advantage over blowfish and that is IMHO still
a lot. If des was enabled I guess it would about 3x the performance
of 3des, so about equal to blowfish.

> -c none is still a large security exposure. It is the encryption that keeps
> someone from waiting until after keys pass and then immediately step in and
> either alter data or intercept passwords.

Yes, I do recognize the danger of a man-in-the-middle attack. The only
reasonable place for none would be LANs (because over the net, bandwidth
will be more likely the limiting factor) where the largest danger would
be password sniffing. Also none is most useful for transferring large
data, as speed is not much an issue for small files (3des is fast enough
in such a case). The difference between 1 and 2 sec is small but between
5min and 10min is huge.

> I'm not even sure that I'd support this, but the only way this should go
> into the tree is with a "--with-none" option for configure that is by default
> "without".

I would agree with making it an configure option. Default value is not for
me to decide. What I pledge for is the freedom of choice to
select a weaker cipher in cases where it's use gives more advantages
than disadvantages.

Thanks.
--

Oliver M. Bolzer
oliver@gol.com

GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF