Re: [Monotone-devel] netsync transport encryption?

[Jeronimo Pellegrini]

On Wed, Oct 25, 2006 at 10:09:39PM +0200, Ulf Ochsenfahrt wrote:
> address@hidden wrote:
> >Yes, and I don't think it's a problem.
> 
> 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!

OK, no problem. :-)
I think we agre on most things here.

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

Yes, but it may not be a concern to the team if the mambers upload
often and communicate often too. If this same guy tries to upload
a new revision in the next day, he'll find the problem.
And if he mentions that he fixed a bug in revision NNN, others will
say "it isn't there!"

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

Ah, right, now I get it. :-)

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

I haven't implemented it like that, but it should be possible.

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

Yes!
Keep a list of users in the database, in a special dir.
Revoking means changing the current key and removing the user from that
directory. Then encrypt the new key for all users in that directory and
tell them to resync.

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

That would be O (RSA x users) every time you commit... Is it necessary?
(Or DSA, or whatever other asymetric algorithm)

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

Apso stores a map of revisions onto keys...
There is a paper in the project page that describes the protocol.

> Do you have a project homepage or mailing list?

Yes. But the implementation is a prototype, not ready for production.
:-(

http://aleph0.info/apso/

J.