Google Summer of Code: Encrypted branch/repository format status

[Robert Collins]

On Tue, 2007-07-17 at 10:34 -0500, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Pool wrote:
> > On 7/17/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Bogdano Arendartchuk wrote:
> >> > Hello,
> >> >
> >> > I'm working on the encrypted repository and branch format for Bazaar.
> >> >
> >> > Currently I'm coding a repository format that is intended to write
> >> in the
> >> > disk all the data slightly scrambled. This is a protype and nothing is
> >> > encrypted at all, the objective is to know better the Bazaar
> >> code/design
> >> > and also plan what can be reused and what should be reimplemented in
> >> order
> >> > to fit the application needs.
> > 
> > The other question in my mind is whether this really needs to come in
> > at the knit level.  Could you instead interpose an encrypting
> > transport for access to some files?  I realize random access may be a
> > bit hard to get just right, but that's probably no worse than for
> > doing it in a knit... The transport interface is pretty stable.

Doing it in a transport layer would essentially involve creating an
encrypted VFS that works smoothly over FTP etc. I think thats a harder
problem that working within our storage later. (It has to be safe
against concurrent writers because its outside the locking logic).

> Transport would probably be interesting. I'm not sure how it would
> encrypt the filenames in the same way, but it at least seems possible.
> You could have a custom BzrDir that at .open() time would re-wrap its
> Transport in an EncryptedTransportWrapper, which would munge filenames
> and file contents as appropriate.
>
> I really think that anything of this sort of security should have a bit
> of discussion about what sort of attacks are possible, and what it is
> trying to defend against.
>
> Specifically, some things that I don't think he is trying to hide:
> 
> a) That there is a Bazaar Branch of some sort at that location. (This
> would effect discovery, and some other things). Specifically, you would
> probably want to obfuscate the '.bzr' directory if you were trying to
> avoid this. Since we aren't, it means that .bzr/ and the general
> meta-information files can stay put (you don't have to hide where
> .bzr/repository/inventory.knit is, you just want to hide the *contents*
> of the file).
> 
> b) When information is added to the repository. It would be possible to
> pre-allocate a certain amount of data and fill it with randomness, and
> always modify some of the randomness to hide just what is being updated
> and when. I'm pretty sure we aren't trying for this level of security.
> If someone really wants more, they should look into something like
> TrueCrypt and mount an encrypted filesystem, and then publish their
> encrypted volume.

right.

> c) We aren't trying to prevent a hacker who has local root access from
> reading the contents from in-memory. Not to mention that once you have
> done a checkout, you have the real contents on-disk.
> 
> d) We aren't trying to prevent someone who *has* access from
> accidentally checking out a working copy in the public location (maybe
> we are).

I don't think so.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070720/0d8eae5d/attachment.pgp