Re: [Cryptography] MITM source patching [was Schneier got spooked]
re: git, signed commits, log verification, etc Monotone supports a good bit of PKI within it... http://monotone.ca/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Mon, Sep 16, 2013 at 2:48 PM, zooko wrote: > On Sun, Sep 08, 2013 at 08:28:27AM -0400, Phillip Hallam-Baker wrote: > > > > It think we need a different approach to source code management. Get rid > of > > user authentication completely, passwords and SSH are both a fragile > > approach. Instead every code update to the repository should be signed > and > > recorded in an append only log and the log should be public and enable > any > > party to audit the set of updates at any time. > > > > This would be 'Code Transparency'. > > This is a very good idea, and eminently doable. See also Ben Laurie's blog > post: > > http://www.links.org/?p=1262 > > > Problem is we would need to modify GIT to implement. > > No, simply publish the git commits (hashes) in a replicated, append-only > log. > Well people bandwidth is always a problem. But what I want is not just the ability to sign, I want to have a mechanism to support verification and checking of the log etc. etc. > So what's the next step? We just need the replicated, append-only log. > Where I am headed is to first divide up the space for PRISM-PROOF email between parts that are solved and only need good execution (message formats, mail integration, etc) and parts that are or may be regarded as research (key distribution, key signing, PKI). Once that is done I am going to be building myself a very lightweight development testbed built on a SMTP/SUBMIT + IMAP proxy. But hopefully other people will see that there is general value to such a scheme and work on: [1] Enabling MUAs to make use of research built on the testbed. [2] Enabling legacy PKI to make use of the testbed. [3] Research schemes Different people have different skills and different interests. My interest is on the research side but other folk just want to write code to a clear spec. Anyone going for [3] has to understand at the outset that whatever they do is almost certain to end up being blended with other work before a final standard is arrived at. We cannot afford another PGP/SMIME debacle. On the research side, I am looking at something like Certificate Transparency but with a two layer notary scheme. Instead of the basic infrastructure unit being a CA, the basic infrastructure unit is a Tier 2 append only log. To get people to trust your key you get it signed by a trust provider. Anyone can be a trust provider but not every trust provider is trusted by everyone. A CA is merely a trust provider that issues policy and practices statements and is subject to third party audit. The Tier 2 notaries get their logs timestamped by at least one Tier 1 notary and the Tier 1 notaries cross notarize. So plugging code signing projects into a Tier 2 notary would make a lot of sense. We could also look at getting Sourceforge and GITHub to provide support maybe. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sun, Sep 8, 2013 at 2:28 AM, Phillip Hallam-Baker wrote: > This would be 'Code Transparency'. > > Problem is we would need to modify GIT to implement. Git already supports signed comments. See the "-S" option to "git commit. If you're paranoid, though, that still leaves someone getting on your dev box and slipping in a small patch into code you're about to commit, or just using your pgp keys themselves... Next problems -- getting the right key to verify against. Knowing what sets of keys are allowed to sign for a particular project. > Website: http://hallambaker.com/ -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On 09/08/2013 05:28 AM, Phillip Hallam-Baker wrote: every code update to the repository should be signed and recorded in an append only log and the log should be public and enable any party to audit the set of updates at any time. This would be 'Code Transparency'. Problem is we would need to modify GIT to implement. Why is that a problem? GIT is open-source. I think even *I* might be good enough to patch that. Ray ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sat, Sep 07, 2013 at 07:42:33PM -1000, Tim Newsham wrote: > Jumping in to this a little late, but: > > > Q: "Could the NSA be intercepting downloads of open-source > > encryption software and silently replacing these with their own versions?" > > A: (Schneier) Yes, I believe so. > > perhaps, but they would risk being noticed. Some people check file hashes > when downloading code. FreeBSD's port system even does it for you and > I'm sure other package systems do, too. If this was going on en masse, There is a specific unit within NSA that attempts to obtain keys not in the key cache. Obviously, package-signing secrets are extremely valuable, since they're likely to work for hardened (or so they think) targets. For convenience reasons the signing secrets are typically not secured. If something is online you don't even need physical access to obtain it. The workaround for this is to build packages from source, especially if there's deterministic build available so that you can check whether the published binary for public consumption is kosher, and verify signatures with information obtained out of band. Checking key fingeprints on dead tree given in person is inconvenient, and does not give you complete trust, but it is much better than just blindly install something from online depositories. > it would get picked up pretty quickly... If targeted, on the other hand, it > would work well enough... signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sun, Sep 8, 2013 at 1:42 AM, Tim Newsham wrote: > Jumping in to this a little late, but: > > > Q: "Could the NSA be intercepting downloads of open-source > > encryption software and silently replacing these with their own > versions?" > > A: (Schneier) Yes, I believe so. > > perhaps, but they would risk being noticed. Some people check file hashes > when downloading code. FreeBSD's port system even does it for you and > I'm sure other package systems do, too. If this was going on en masse, > it would get picked up pretty quickly... If targeted, on the other hand, > it > would work well enough... > But is the source compromised in the archive? It think we need a different approach to source code management. Get rid of user authentication completely, passwords and SSH are both a fragile approach. Instead every code update to the repository should be signed and recorded in an append only log and the log should be public and enable any party to audit the set of updates at any time. This would be 'Code Transparency'. Problem is we would need to modify GIT to implement. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
