Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756038AbbEUXBL (ORCPT ); Thu, 21 May 2015 19:01:11 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60817 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754940AbbEUXBI (ORCPT ); Thu, 21 May 2015 19:01:08 -0400 Date: Fri, 22 May 2015 01:01:05 +0200 From: "Luis R. Rodriguez" To: Andy Lutomirski Cc: David Howells , Andy Lutomirski , Rusty Russell , Michal Marek , Matthew Garrett , keyrings@linux-nfs.org, Dmitry Kasatkin , "linux-kernel@vger.kernel.org" , Seth Forshee , LSM List , David Woodhouse Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4] Message-ID: <20150521230105.GL23057@wotan.suse.de> References: <20150520162059.GC10473@localhost> <20150521213829.GH23057@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2944 Lines: 65 On Thu, May 21, 2015 at 03:47:49PM -0700, Andy Lutomirski wrote: > On Thu, May 21, 2015 at 3:31 PM, Luis R. Rodriguez wrote: > > > > Well as good as you are in 10 years we'll have better ones. So when > > module signature went into the kernel the real expectation should have > > been: > > > > This code looks good now but is going to be complete shit and > > breakable a few years from now. > > > > Hence my first implicit and now explicit claims on dog and pony shows. > > Best thing we can do IMHO is to just allow us to replace stupid human > > code with better human code later, and eventually hopefully better AI > > code, and so on. Since you don't have time for a real replacement > > maybe what we can do is at least document / target / agree for what > > pipe dream we want and shoot for it with time. Hopefully folks will > > find time to implement it. > > I disagree. I'm a firm believer in security proofs. While I'm not > trained in formal crypto proofs, I can sketch out a proof of why a > system that properly tags its signatures is secure against a > reasonable threat model. I can also show why that proof wouldn't work > for a scheme without tags, and I can demonstrate the actual weakness > in a scheme without tags. > > In ten years, the only reason a scheme that I say looks good would be > because (a) I screwed up, (b) an underlying assumption is wrong, or > (c) the implementation is subtly wrong. In particular, it won't fail > because I'm insufficiently clever. > > A real professional expert would be less likely to screw up. > > (For reference, I wrote an actual doctoral thesis involving crypto.) OK, I think what I mentioned still holds: these premises must hold true for a period of time, and provided you have all information. You cannot have all the information, so the "threat model" depends on the reviewer, and the information they have access to. So, still its still a dog and pony show, at least a temporal one or one with a set of clauses. > > In the meantime should that block current dog and pony show trading? I > > don't think so. > > Yes, since I can demonstrate the actual weakness without tags, But you don't want to do the work to provide a better replacement? > and > crypto is notoriously hard to fix once done poorly and there's a great > history of obviously-theoretically-weak systems being meaningfully > attacked in the real world. See, for example, every single old > SSL/TLS cipher. (And yes, the crypto community knew what was wrong in > theory and how to fix it when the protocol was designed. People just > didn't pay attention.) Its a fair argument, but still -- we have the vaporware problem. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/