Re: [Monotone-devel] Monotone Security

[Peter Stirling]

On 15 Oct 2008, at 8:04 pm, Daniel Carrera wrote:

> Peter Stirling wrote:
> > If a key is compromised then they can sign revisions in the past.
>
> Ok, I see a DOS attack here. If you know when the revision happened,  
> it is easy to know which revisions you want to keep and which you  
> want to remove; but removing the signatures from the revisions you  
> want to keep might be a lot of hassle.
>
> Perhaps it is possible to write a script that does something like  
> this:
>
> foreach (revision earlier than <date>) {
>    if (revision is signed by compromised key) {
>        if (revision has two signatures) {
>            remove_signature_with_compromised_key();
>        } else {
>            sign_revision_with_new_replacement_key();
>            remove_signature_with_compromised_key();
>        }
>    }
> }
>
> This solution is imperfect. If a revision really was supposed to be  
> signed twice, that information will get lost. And I'm not even sure  
> if a routine like this is easy to write.
Looking at your pseudo-code all I see is re-signing all revisions  
signed with the (now-duff) key
that assert their date as before a particular value.

The problem is that if you have the old key available to you, then you  
can create revisions that
will pass your test for 'earlier than <date>', regardless of when they  
were actually signed.
Digital signatures only allow you to state unequivocally that data was  
asserted by someone with
access to the key. It's up to the recipient to decide whether to trust  
that assertion.

Your code is workable though, if you can find a repository which  
hasn't yet been poisoned.

The problem is probably not quite as dire as I originally thought.

Revisions include the hash of the parent revision so the DAG can't be  
spoofed (if I understand the
mechanism correctly), so you only need to examine revisions chains  
that are at the head of a branch
that are signed by the 'evil' key.

If you start from the last revision signed by a 'good' key you can  
assign someone to look at each
child revision in turn, to see if it should be kept. Once you find a  
bad revision, it, and all
its children can be kill_revision_locally'd by a script.

With 10,000,000 bogus branch heads you might be forced to simply  
delete (recursively) every revision
signed by the key that is at the head of a branch (though this would  
risk losing useful stuff).