On Tue, Feb 17, 2004 at 07:52:16PM -0500, Greg Troxel wrote:
> RPC2?  This is tricky; encryption doesn't give you integrity.  From
> what I read in rpc2-src/secure.c, there is the concept of
> encrypt/decrypt, but no expansion is allowed (leaving no room for a
> message integrity code) and the encryption must work on arbitrary byte
> boundaries.  I suspect a mode like ciphertext stealing would work
> here, but I'm rusty on the details.

I think that RPC2 needs 3 important changes. Variable keylength instead
of fixed 8 byte keys, allow for padding (expanding) the encrypted
packets, and an integrity checksum. I also believe that adding
encryption to SFTP is a lower priority issue, the bulk data encryption
could possibly be done (more efficiently) at a higher layer.

Because each RPC2 packet can be lost, a CBC cipher is not doable.
However it should be possible to add an IV to each packet which makes
identical packets encrypt differently (similar to WEP encryption).
(ofcourse that could get us the whole nastiness of trying to avoid weak
IVs depending on the cipher we use etc).

Which is why 'off-the-shelf' solutions like IPsec and SSL are nice,
smart people have put some serious thought into it. Too bad there isn't
an SSL over UDP version.

> It was not apparent on reading the code how authentication is handled
> (separately from encryption, it seems, but I couldn't follow it).

Authentication is mostly in rpc2a.c, there is one big function
'RPC2_NewBinding' that steps through the whole authentication sequence.
I just read through it and it is the suggested alternative in the ban
paper.

Jan