Lapo Luchini <[EMAIL PROTECTED]> wrote: > EXCEPT when the revocation reason is "key compromise", in that case > you can't even trust old signatures from that key. ;-) (as they > could be only "apparently" old, or the compromise could have been > discovered only much after the damage was done)
Practically speaking, what would an attack look like that might have a chance of being successful? i.e. Could you give examples, or a test case to peruse? 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. I say changes because additions are should be pretty straight forward to pick out. Let me give you these parameters: We know that key [EMAIL PROTECTED] is the compromised key, a key whose password is known and used by a 3rd party. It was discovered today, 13 October 2005 to have been compromised on 1 October, 2005. It had been in used legitimately since Jan 1, 2005. 1. How could this key be used to change history (your "apparently old" assertion)? 2. How could changes using this key since the supposed compromise date be missed in an audit? _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
