Jonathan Wilkes: > >From: Mike Perry <mikepe...@torproject.org> > > [...] > > > This is where deterministic builds come in: any individual can use our > > anonymity network to download our source code, verify it against public > > signed, audited, and mirrored git repositories, and reproduce our builds > > exactly, without being subject to such targeted attacks. If they notice > > any differences, they can alert the public builders/signers, hopefully > > using a pseudonym or our anonymous trac account. > > > > This also will eventually allow us to create a number of auxiliary > > authentication mechanisms for our packages, beyond just trusting the > > offline build machine and the gpg key integrity. > > Interesting. Questions: > > 1) I'd imagine in your case that a large portion of > users aren't going to want to compile the software, and it seems at > least like they could still be good citizens by verifying the binaries > they download against what a random sampling of mirrors say they > should look like. Is there a tool out there they can use to do this?
Right. First, let me say just to make this fully clear: not everybody needs to compile their own bundles to protect against attack. This isn't security-through-self-compilation a-la Gentoo. You only need to compile a bundle if you suspect either nobody else in the world is privately verifying the bundles (and right now, you might be correct), *or* if you suspect the GPG keys are compromised and you specifically are being fed targeted, fake-signed bundles that none of the private verifiers actually see. However, I would still like to mitigate even these targeted attacks. Here's my thoughts so far: The immediate plan is to publish the full set of detached GPG signatures for all of the matching public builds to start, so that we at least require multikey compromise to mount the targeted fake bundle+fake signature attack. Hopefully at least one of the builders will use a hardware GPG signing token, to make such theft harder. (It's on my TODO list to figure that out for my own keys..) Later, as I alluded to in that next paragraph, we can do defense-in-depth things like place a URL that lists the approved official bundle hashes along with a SHA256SUM for that URL's contents in the Tor Consensus document (which is also a multikey signed document using offline keys and yearly signing key rotation). We can also verify the consensus document hash itself (including the package URL+hash) with a "double Ben Laurie" multipath+notary and/or multisigned hashtree check... I would like to do all of these things (especially the "double Ben Laurie" backup Tor Consensus verification, because I don't really think we should trust the consensus keys fully as we do now), but there's also a lot of other things to do at Tor first. Who knows what shiny new explosion of doom will distract me next. It's an exciting place to work! > 2) Do you use Tor's git version id (the hash) for the > release as the random seed string? Seems like that would be a > good precedent to set in case other projects start using this > method, too. Not sure exactly what you're asking here. For GCC's -frandom-seed, we just use "tor" as the string. I'm not aware of any reason why that seed needs to ever change (my understanding is that it is only used for symbol mangling to avoid static/namespace collisions). We also include the full set of git hashes, version tags, and input source hashes in the bundles themselves, so you know exactly what went into your bundle if you want to try to match it at a later date... -- Mike Perry
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
