Re: [Monotone-devel] netsync transport encryption?

[Ulf Ochsenfahrt]

address@hidden wrote:
> 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.

Ok. :)

> 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.

I'm not saying it's a problem. What I was trying to say is that every 
security measure targets a certain attack. And a security measure isn't 
always successfull in preventing that type of attack. And sometimes, a 
measure actually makes security worse.

I was just critizising that encrypting the database may not be the 
appropriate measure for the current use case. And then again, it might 
be. Sorry if I came over too harsh. If you're trying to built an db 
encrypted distributed vcs, by all means do!

> > 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).

Right, and now we're talking about data integrity. Monotone (alread) 
ensures data integrity with cryptographically signed hashes. On an 
untrusted host, this can still be a problem under certain circumstances. 
If the host deletes a branch head, then only the one who uploaded that 
revision can detect this.

> > 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.

Yeah well. It's not good enough against certain types/cases of 
evesdropping. That was my point entirely.

> > 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.

Sorry, I didn't mean you specifically. I read it in an earlier mail and 
was too lazy to split it into another.

*note to self: don't write to mailing lists when you're in a hurry*

> > 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...

Of course, you have to find a balance.

> > 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.

I meant: monotone should drop it's proprietary message signing and use 
GPG instead. :D

Encrypting the db is definitely an interesting approach. Actually, this 
might be useful for the project I'm currently working at (at 
University). Is it possible to encrypt different branches with different 
keys? That would allow me to have something like a 'private area' on my 
public archive without restricting the set of users that are allowed to 
pull (or sync) a particular branch. And indeed, I could allow certain 
users access by giving them the branch key. The question is, how can I 
revoke access? I could encrypt the next revision with a new key for 
example, but then I'd have to give everyone (except the one I'm 
revoking) the new key.

Or, I could encrypt every revision with a new key and encrypt the new 
key with the public keys of everyone I want to be able to access that 
revision and store them with the revision. And I'd have to ensure they 
can access every parent revision, so I'd also encrypt the keys of the 
parent revisions with the revision key and store them with that revision.

Do you have a project homepage or mailing list?

Cheers,

-- Ulf

smime.p7s
Description: S/MIME Cryptographic Signature