Coda File System

Here's our first patch (rpc2-security)

From: Max Berger <>
Date: Thu, 23 Nov 2000 00:01:50 +0100 (CET)

the impatient:

On Tue, 21 Nov 2000, Jan Harkes wrote:
> I would advise to leverage off existing authentication and encryption
> mechanisms provided by SASL and SSL. I don't know how much of SSL is
> useable for UDP, but it should at least be able to provide the
> encryption routines.
I don't know about sasl, but ssl is usually used in stream
connections. The reason we chose blowfish are
- its fast
- its free and
- it can be used to encrypt and/or decrypt in-place, which saves us a lot
of modifying-trouble
and (last, but not least)
- it works!

> Patents are potentially still a worry, even on european servers. The
> US export regulations have been opened a lot for opensource software, so
> that shouldn't be that much of a problem.

These are the reasons for RSA and BlowFish, both are (now) patent-free. I
don't know about the export regulations, but it we kept the blowfish
module seperate, which will make it easy to provide empty stubs and keep
the actual code on us servers for us and non-us server for non-us

> > Are you interested in this solutions? Has anyone worked on anything like
> > this yet? And last, but not least: Would these thing be sufficient for
> > security?

> Yes, we would definitely be interested. Robert Watson worked on
> improving RPC2 security, but that work was done a long time ago and
> the changes are difficult to merge because RPC2 has seen many internal
> changes.

Ok, the patch is at

> Some problems he encountered were,
> - Need to add support for variable length RPC2_Encryption keys.

> - The binding sequence of RPC2_NewBinding needs to be modified to allow
>   for different authentication schemes.

> - SFTP timestamps retransmitted packets without decrypting/encrypting,
>   breaking SFTP transfers when actual encryption is used.
untested, TBD

> - SFTP encryption might not even be desireable, because we are looking
>   at compression and encryption of container files on the client before
>   sending them and keeping them encrypted on the server.
To be tought about.

> - Integrity of transmitted packets needs to be checked as well
>   (md5/sha/crc32?).

> In any case, it is a hard challenge to make a secure RPC2 system, but
> that probably makes it all the more interesting.

Thanks ;) But we want coda, and we want it with plain passwords. Therefore
securing rpc2 is our only option.

We'd be very happy if you look over this code and think about including it
(or part of it) in the main tree.

> Jan


Max Berger

XSLT:          PGP/GnuPG ID: E81592BC
FSMPI:  F489F8759D4132923EC4 BC7E072AB73AE81592BC 
Received on 2000-11-22 18:02:07