[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Monotone Security
From: |
Peter Stirling |
Subject: |
Re: [Monotone-devel] Monotone Security |
Date: |
Thu, 16 Oct 2008 15:32:07 +0100 |
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).
- [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/14
- Re: [Monotone-devel] Monotone Security, Timothy Brownawell, 2008/10/14
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/15
- Re: [Monotone-devel] Monotone Security, Peter Stirling, 2008/10/15
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/15
- Message not available
- Message not available
- Re: [Monotone-devel] Monotone Security,
Peter Stirling <=
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Jack Lloyd, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Nathaniel Smith, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Thomas Keller, 2008/10/17
- Re: [Monotone-devel] Monotone Security, Zack Weinberg, 2008/10/16
- Re: [Monotone-devel] Monotone Security, Daniel Carrera, 2008/10/16