"cipher none" alternatives ?

[Jason Stone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> (I had observed that for smaller files scp -c 3des was noticably
> slower than NFS/ftp/scp -c none on 100BaseT links, though not on
> 10BaseT)

3des is extremely slow, slower by far than almost any other cipher in
common usage.  I remember someone doing some time trials for different
ciphers and posting to the list a couple months ago - check the
archives.  In any event, try blowfish or aes instead of 3des.


> The datafiles themselves do not contain sensitive data, but we'd like
> to use some better authentication method than ftp and preferably
> something that would easily go through a firewall. As I understood
> things, scp -c none with RSA authentication offers something like
> that.

The scheme you're talking about isn't vulnerable to password sniffing, but
it _is_ vulnerable to hijacking.  The crypto in this case is serving to
authenticate each individual packet as well as hide the data, so when you
get rid of the crypto, an attacker can take over either end of the
connection, inject packets (containing commands), etc, even though he
doesn't know the password.

That said, there are other authentication schemes that avoid sending
passwords in the clear.  CHAP stores the password in the clear but never
sends it over the wire.  OPIE (aka, S/Key) is even better as it neither
sends nor stores the password in the clear.

Before ssh was in wide use, I had my users use opie-ftpd.


> We could presumably use HTTP GET to suck files if they were placed in a
> webserver tree and use HTTP authentication. I'm not so sure about pushing
> with POST or PUT.

You could also use crypto here too.  Most webservers can trivially be ssl
wrapped (check out stunnel, sslproxy, etc), some webservers have native
support for openssl (apache + mod_ssl is particularly popular), and there
are many available ssl webclients (curl, lynx-ssl, etc).  You can use
either HTTP authentication inside of the ssl stream, or, maybe better, you
can require both the client and the server to authenticate each other with
ssl certs.  (These roughly correspond to password auth and public key auth
in ssh.)  I'm sure that at least one of these combinations can be
configured with a fast, low overhead cipher.


 -Jason

 ---------------------------
 If the Revolution comes to grief, it will be because you and those you
 lead have become alarmed at your own brutality.         --John Gardner



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE6stHqswXMWWtptckRAmGbAJ9p/6D+jvq8F+NFcP+uVouOxjautQCg9HUX
DpxWaAjo+Ynr/FqzE81qDhY=
=jPY5
-----END PGP SIGNATURE-----