Re: [Monotone-devel] netsync transport encryption?

[jp+mtn]

On Wed, Oct 25, 2006 at 04:29:30PM +0200, Ulf Ochsenfahrt wrote:
> Jeronimo Pellegrini wrote:
> >If you can label computers as "trusted" and "posibly hostile", then
> >you can encrypt the database -- and never checkout or have the
> >clear version on the hostile hosts. You would only decrypt it in trusted
> >hosts where you'd keep your workspace. A solution based on
> >communication encryption works also, but then you would have
> >all hosts as "possibly hostile". It depends on your needs.
> >
> >My point is that if you encrypt the database, encrypting the channel
> >is not necessary (because the diffs are sent encrypted already), and
> >you can use plain netsync.
> 
> Not true. Encrypting the database and encrypting the channel solve 
> different problems. And encrypting the database isn't the golden bullet 
> you seem to assume it to be.

I'm sorry I didn't write what I was thinking. :-) I didn't really mean it's
a substitute for channel encryption always. I just meant that it may substitute
connection enrcyption if you're not worried about others knowing that
you store a Monotone database on the server.

I agree that knowing the number of deltas and their sizes is not really
good, but may be acceptable, depending on your needs.
Actually, when I first thought about this problem, before starting to
work on the implementation, I thought that I'd use ssh as a tunnel
and use encrypted filesystems on workstations where checkouts exist. :-)

> If you put an encrypted database on an untrusted host, you still have 
> several problems:
> 1. the host knows that there is a database

Yes, and I don't think it's a problem.

> 2. the host can log all communication in both directions

Yes.

> 3. the host can corrupt the database

Yes, but it's distributed and can be put in another host if necessary.
And the corruption wouldn't hurt since Monotone already stores hashes
of all revisions. The best (or worse) that the host can do is to delete
random revisions. This would likely be noticed in a short time by the
users.
The host can also corrupt the database if you're encrypting the channel
only -- if the host is hostile, all you can do is to assure that the
host will not get your content (and the encrypted database works for
that).

> Encrypting the connection helps against accidental or willfull 
> evesdroppers. (Though they still know that you did communicate.) If you 
> don't encrypt the connection, evesdroppers also know:
> 1. what you do (monotone sync)

Yes.

> 2. how many revisions

And the encrypted content of all revisions, with their sizes. This is
something that I'll think about, but *if* this is a problem to you
then ssh immediately comes to mind.

> 3. revision ids

It would be possible to also enrcypt revisin IDs, although I didn't
implement that as it would involve one more translation from
clear ID to encrypted ID...

> And then there's authentication. monotone already authenticates users so 
>  you can disallow (or allow) certain users to read and/or write from 
> the database.

Yes, but that can be done with or without an encrypted database.

> There are also problems with citing Bruce Schneier's "Applied 
> Cryptography". Mr. Schneier himself has actually called mixed feelings 
> about that book (go read "Beyond Fear" if you don't believe me).

I never cited that book as I'm not a fan of it. If I were to cite a
book, I'd cite either Wenbo Mao's "Modern Cryptography: theory and practice"
or "Handbook of Applied Cryptography" by Menezes & others.

> The problem I see with 
> encrypting the database or the connection is that it's so damn easy to 
> make just a tiny programming mistake and fuck everything up (see ssh for 
> example). And then for the sake of backwards compatibility, you have to 
> keep it that way.

Yes, true for all cryptographic protocols and algorithms...

> For an encrypted connection, I'd much rather trust ssh 
> and/or ssl tunnels. ssh/ssl has had a lot of eyes looking at it, which 
> you can see from the fact that security issues _have_ been found.

That's a good point. But if you take it to an extreme, you won't ever
have new implementations (or new algorithms/protocols proposed), because
when they are created, there are not enough eyes looking at them...

And you can always be careful. If a protocol or algorithm is broken
you have a problem, but at least the *implementation* can be done
carfully enough. For example, Monotone never cause database corruption
for anyone, just because it was decently implemented and every
release is heavily tested (automatically).

> That said, I am against having connection encryption (and all its 
> overhead) in monotone. (On a side-note, I'd find it good if monotone 
> could use gpg for signing and authentication. gpg is well-known and 
> well-looked-at. Of course, it would add an external dependency, 
> unfortunately.)

Wouldn't be a dependency if you could build Monotone without GPG and
have it as an option (set it to GPG when you init the database, for
example). And Monotone would only use GPG if it's available.

J.