From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sandy Harris Date: Tue, 19 Sep 2017 19:04:29 +0000 Subject: Re: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <20170916130034.17706-1-Jason@zx2c4.com> <2681038.03lnYPhpsa@tauon.chronox.de> <20170919133959.5fgtioyonlsdyjf5@thunk.org> In-Reply-To: <20170919133959.5fgtioyonlsdyjf5@thunk.org> To: Theodore Ts'o , "Jason A. Donenfeld" , Stephan Mueller , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, kernel-hardening@lists.openwall.com, LKML , David Howells , Eric Biggers , Herbert Xu , Kirill Marinushkin , Ard Biesheuvel , Ilhan Gurel , security@kernel.org, stable@vger.kernel.org On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude about this FIPS silliness. ... > > Let me add one more reason why FIPS compliance for the kernel is just > ***stupid***. The way FIPS compliance works, you have to pay hundreds > of thousands of dollars to a FIPS certification lab to certify a > specific binary, complete with the exact build environment (compiler, > binutils, etc.) used to build that kernel binary. > > The moment you need to make a change --- say, to fix a critical > zero-day security bug --- this breaks the FIPS certification, ... > > You might say that FIPS certification != FIPS compliance. Sure, but > the only silly people who care about FIPS compliance also need FIPS > certification, for the US Goverment signoff. I do not think it is just the US that matters here. If I understand Stefan correctly, one of his concerns is German (or EU?) gov't standards that are somehow related. I'm very hazy on details. I emphatically agree with Ted on some points here. Making FIPS certification a goal for kernel development would be really dumb. Having multiple RNGs available & compile-time options to select among them also looks silly to me; we just need one good one. On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan? I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751502AbdISTEe (ORCPT ); Tue, 19 Sep 2017 15:04:34 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35809 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751391AbdISTEb (ORCPT ); Tue, 19 Sep 2017 15:04:31 -0400 X-Google-Smtp-Source: AOwi7QBweIjwqHhf1h2+wrE+Ps6gCNmzVfHSRWKw9sKJuiq827WHVMjqlZCb2ps+QRH3yhgfircmjbrwZWPP0PcItY8= MIME-Version: 1.0 In-Reply-To: <20170919133959.5fgtioyonlsdyjf5@thunk.org> References: <20170916130034.17706-1-Jason@zx2c4.com> <2681038.03lnYPhpsa@tauon.chronox.de> <20170919133959.5fgtioyonlsdyjf5@thunk.org> From: Sandy Harris Date: Tue, 19 Sep 2017 15:04:29 -0400 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto To: "Theodore Ts'o" , "Jason A. Donenfeld" , Stephan Mueller , linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, kernel-hardening@lists.openwall.com, LKML , David Howells , Eric Biggers , Herbert Xu , Kirill Marinushkin , Ard Biesheuvel , Ilhan Gurel , security@kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude about this FIPS silliness. ... > > Let me add one more reason why FIPS compliance for the kernel is just > ***stupid***. The way FIPS compliance works, you have to pay hundreds > of thousands of dollars to a FIPS certification lab to certify a > specific binary, complete with the exact build environment (compiler, > binutils, etc.) used to build that kernel binary. > > The moment you need to make a change --- say, to fix a critical > zero-day security bug --- this breaks the FIPS certification, ... > > You might say that FIPS certification != FIPS compliance. Sure, but > the only silly people who care about FIPS compliance also need FIPS > certification, for the US Goverment signoff. I do not think it is just the US that matters here. If I understand Stefan correctly, one of his concerns is German (or EU?) gov't standards that are somehow related. I'm very hazy on details. I emphatically agree with Ted on some points here. Making FIPS certification a goal for kernel development would be really dumb. Having multiple RNGs available & compile-time options to select among them also looks silly to me; we just need one good one. On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan? I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws? From mboxrd@z Thu Jan 1 00:00:00 1970 From: sandyinchina@gmail.com (Sandy Harris) Date: Tue, 19 Sep 2017 15:04:29 -0400 Subject: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto In-Reply-To: <20170919133959.5fgtioyonlsdyjf5@thunk.org> References: <20170916130034.17706-1-Jason@zx2c4.com> <2681038.03lnYPhpsa@tauon.chronox.de> <20170919133959.5fgtioyonlsdyjf5@thunk.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude about this FIPS silliness. ... > > Let me add one more reason why FIPS compliance for the kernel is just > ***stupid***. The way FIPS compliance works, you have to pay hundreds > of thousands of dollars to a FIPS certification lab to certify a > specific binary, complete with the exact build environment (compiler, > binutils, etc.) used to build that kernel binary. > > The moment you need to make a change --- say, to fix a critical > zero-day security bug --- this breaks the FIPS certification, ... > > You might say that FIPS certification != FIPS compliance. Sure, but > the only silly people who care about FIPS compliance also need FIPS > certification, for the US Goverment signoff. I do not think it is just the US that matters here. If I understand Stefan correctly, one of his concerns is German (or EU?) gov't standards that are somehow related. I'm very hazy on details. I emphatically agree with Ted on some points here. Making FIPS certification a goal for kernel development would be really dumb. Having multiple RNGs available & compile-time options to select among them also looks silly to me; we just need one good one. On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan? I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html