-----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----- _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
