[Monotone-devel] Re: key trust

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chad Walstrom wrote:
> Could you give examples, or a test case to peruse?

Mhh, I was strictly thinking from a cryptography point of view, not
specifically in the monotone scenario, but let me think...

> I ask this because it seems exceptionally difficult to use a
> compromised key to make *undetectable* "changes" in a database that
> relies upon immutable history and a distributed nature.

Mhh, one "main" difference is between "undetectable by humans" and
"automatically/intrinsically detectable by the system itself": creating
a new revision, with a diff big enough to "hide" some serious bug, could
be signed by the "serious developer key" who was compromised and (if the
"serious developer" is maybe in holidays and not noticing it) get used
to produce the next release of the project, maybe?

I must admit that having the whole history (and no way to delete it) it
a *BIG* security net for the whole system, of course.

> It was discovered today, 13 October
> 2005 to have been compromised on 1 October, 2005.

Another possible complication is when you discover by chance that the
system was compromises but you have no idea of WHEN it was.

> 1. How could this key be used to change history (your "apparently old"
>    assertion)?

In the way of working of monotone (mainly thanks to the
cryptographically secure hash that doesn't permit to change content
without changing the hash of the file and, thus, of the revision) I
can't see any way except adding a new version.

But of course a new "head" appearing suddenly and very old might be
suspicious (but the off-line nature of monotone could partly "justify"
it as a developer that long forgot to sync).

> 2. How could changes using this key since the supposed compromise date
>    be missed in an audit?

An human audit, I don't think it can, but humans are fallible, and if
the key was being compromised for some months, well, it's not very easy
to think what can be done =)

For some projects (non open source ones especially, not that I like
them, but they do exist ;-)) the simple fact that the person can have
*access* via the key is a problem, even if it can do no damage.

Moreover, I think a sufficient reason is that working in cryptography
it's surprising how many times you are led to think "no way THIS can
affect THAT" and, sooner or later, it INVARIABLY does, so it's much
better to stay on the safe/paranoid side.
(as a silly example: ok, MD5 was found a collision, but it's not broken,
because you can't build a SPECIFIC collision, just produce two
meaningless messages with the same hash... and some months later someone
produces a nice PS document that can print different texts depending on
a part of the text that is not printed, thus being able to actually use
practically an attack that was not considered feasible just a few days
before)

Anyway, I don't really know of I would prefer monotone to be like it is,
using x.509, or using OpenPGP.
Probably the first, if well done, might be adequate.
Basing on the last would provide an existing method to give trust to key
identities, but of course to monotone it's not VERY important whose key
it is, only that "it is the same key that committed very good code in
the last 12 months".

- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkNO4wAACgkQaJiCLMjyUvvIJACcDE0B2ls1AB2dfVaHUGYauWA4
PDsAnRbSX0AHuI3w17LBq21JUJInk5KD
=DRMf
-----END PGP SIGNATURE-----