On Mon, Feb 24, 2014 at 06:51:37PM -0800, Russ Allbery wrote: > Brute-forcing the key just requires compute cycles. There is essentially > no chance of discovery and no risky activity at all until you start > actually using the key. ...which reminds me of http://www.enricozini.org/2008/tips/audit-uploads/ which was a prototype of creating an audit log of key usage in debian. However, for the audit log to be usable as an audit log without giving a false sense of security, it should be complete, and really cover all instances of key usage in Debian. This means hooking into any place where a signature verification or a decryption actually happens in Debian: I can think of uploads, db.debian.org, voting, keyring requests, RT tickets filed, emails received by lists or the BTS: are there more? I see the job as not so much technically complex[1] as socially complex: since I would not trust auditing an incomplete audit log, I fear that a missing or badly implemented data source could invalidate all the system. So I can't just open vim and write the code: auditing key usage in package uploads requires someone who knows dak inside out, and can commit to maintaining notification triggers in all obscure corners where keys are used, now and in future updates of the ftp-master toolchain. Same goes for any other bit of Debian. The starting point for this work is probably this, then: is it just me, feeling that we have a problem here, or am I actually in the good company of people who can do their bit? Ciao, Enrico [1] For realtime auditing, we now have a rabbitmq server. Or collection could be decoupled in one audit log per team, which are then aggregated by a separate project. Or they can be submitted to a central collection point, like a new ad-hoc bit of contributors.debian.org. I don't see anything technically difficult here. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: Digital signature