Re: [Apso-devel] Hiding revision IDs

[Jeronimo Pellegrini]

On Thu, Oct 26, 2006 at 01:10:34PM +0200, Ulf Ochsenfahrt wrote:
> Jeronimo Pellegrini wrote:
> >This was brought up by Ulf Ochsenfahrt on Monotone-devel.
> >
> >Currently, Apso stores encrypted deltas in files whose name
> >is the revision ID.
> >
> >Suppose you're working on project MyBSD, which is a modified version
> >of the FreeBSD kernel. Then one day you resync with the FreeBSD
> >tree. This delta from the BSD tree is well-known, and it would
> >show to an attacker that you are working on a fork of FreeBSD.

My FreeBSD example wasn't good... Suppose it was Xaraya, which is a
project taht uses Monotone. You'd see the same SHA1 sum in the Xaraya
tree and in the "secret" tree taht forked Xaraya.

> I've also thought about this. Maybe there is a better way to do this. I 
> don't know the internal data structure, so I'll just give it a shot. 
> Correct me if I'm making any incorrect assumptions.

You can also see the paper on the project homepage, which describes
the sync protocol.
The info file in the sources is a bit outdated, I think.

> The revision id is a SHA1 checksum, so you can't tell anything just from 
> the number.

Except if this same revision was in some other tree that the attacker
knows...

> However, there is the manifest, and the manifest correlates 
> the revision id to the revision contents. Now if you'd encrypt the 
> manifest, that would help with reducing the amount of 'leaked' 
> information. However, that means you can't sync anymore, because sync 
> needs to know what is contained in the revision.

I'm not sure we're on the same page. :-)

Apso will not encrypt just the deltas; it encrypts the whole revision,
including the metadata:

1. Get the packets for fdata, fdelta, rdata
2. Concatenate them
3. Encrypt

When I need to transfer data from/to the clear and encrypted databases,
I use a special sync protocol that translates revisions between them.

That is fine and doesn't create problems. The problem is that the filename
is the revision name, obtained from "mtn automate get_revision".

Using a random string could work, but I think the implementation relies
on having the revision ID as the filename.

> Now, you could split 
> the manifest. One part contains the relationship between filenames and 
> file contents, and is encrypted. And the other contains just a list of 
> content ids. When syncing, you don't really need to know what the 
> filename is, you just need to figure out which (binary) blobs to transfer.

That would work, but it would become very Monotone-specific. I'd like
that in the future Apso could work with Git, Mercurial and Bazaar.

> This doesn't save against a correlation attack. Someone can look at one 
> revision and see the content ids there and look at another and see those 
> there. If a lot of ids are identical (a lot of unchanged files, which is 
> not unusual), then the attacker can infer that there must be a 
> relationship between those revisions. So when he can see the database, 
> he might be able to infer the revision graph.

The only thing that you can see today in the encrypted database is
the revision IDs and usernames. All the rest (including metadata) is
put together and ran through AES.

J.