The cipher 'none' in OpenSSH
David Rankin
drankin at bohemians.lexington.ky.us
Sat Jan 15 03:28:52 EST 2000
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 at 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
More information about the openssh-unix-dev
mailing list