All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Eric Biggers <ebiggers@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	Paul Crowley <paulcrowley@google.com>,
	Greg Kaiser <gkaiser@google.com>,
	Samuel Neves <samuel.c.p.neves@gmail.com>,
	Tomer Ashur <tomer.ashur@esat.kuleuven.be>,
	Martin Willi <martin@strongswan.org>
Subject: Re: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc
Date: Tue, 20 Nov 2018 13:51:54 -0500	[thread overview]
Message-ID: <20181120185154.GB6401@thunk.org> (raw)
In-Reply-To: <CAHmME9oPGkvEmqvfbav-AOf_P=Z4zWYxvqD3a3QhuOSh_OWd_A@mail.gmail.com>

On Tue, Nov 20, 2018 at 05:24:41PM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > Yes.  In fact it's used for FIPS certification testing.
> > Sure, nobody sane should be doing it.  But when it comes to
> > government certification... :)
> 
> The kernel does not aim toward any FIPS certification, and we're not
> going to start bloating our designs to fulfill this. It's never been a
> goal. Maybe ask Ted to add a FIPS mode to random.c and see what
> happens... When you start arguing "because FIPS!" as your
> justification, you really hit a head scratcher.

There are crazy people who go for FIPS certification for the kernel.
That's why crypto/drbg.c exists.  There is a crazy fips mode in
drivers/char/random.c which causes the kernel to panic with a 1 in
2**80 probability each time _extract_entropy is called.  It's not the
default, and I have no idea if any one uses it, or if it's like the
NIST OSI mandate, which forced everyone to buy an OSI networking stack
--- and then put it on the shelf and use TCP/IP instead.

Press release from March 2018:

https://www.redhat.com/en/about/press-releases/red-hat-completes-fips-140-2-re-certification-red-hat-enterprise-linux-7

    	     	       	   	     	 	- Ted

WARNING: multiple messages have this Message-ID (diff)
From: tytso@mit.edu (Theodore Y. Ts'o)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc
Date: Tue, 20 Nov 2018 13:51:54 -0500	[thread overview]
Message-ID: <20181120185154.GB6401@thunk.org> (raw)
In-Reply-To: <CAHmME9oPGkvEmqvfbav-AOf_P=Z4zWYxvqD3a3QhuOSh_OWd_A@mail.gmail.com>

On Tue, Nov 20, 2018 at 05:24:41PM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > Yes.  In fact it's used for FIPS certification testing.
> > Sure, nobody sane should be doing it.  But when it comes to
> > government certification... :)
> 
> The kernel does not aim toward any FIPS certification, and we're not
> going to start bloating our designs to fulfill this. It's never been a
> goal. Maybe ask Ted to add a FIPS mode to random.c and see what
> happens... When you start arguing "because FIPS!" as your
> justification, you really hit a head scratcher.

There are crazy people who go for FIPS certification for the kernel.
That's why crypto/drbg.c exists.  There is a crazy fips mode in
drivers/char/random.c which causes the kernel to panic with a 1 in
2**80 probability each time _extract_entropy is called.  It's not the
default, and I have no idea if any one uses it, or if it's like the
NIST OSI mandate, which forced everyone to buy an OSI networking stack
--- and then put it on the shelf and use TCP/IP instead.

Press release from March 2018:

https://www.redhat.com/en/about/press-releases/red-hat-completes-fips-140-2-re-certification-red-hat-enterprise-linux-7

    	     	       	   	     	 	- Ted

  reply	other threads:[~2018-11-21  5:25 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 23:25 [RFC PATCH v3 00/15] crypto: Adiantum support Eric Biggers
2018-11-05 23:25 ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 01/15] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 02/15] crypto: chacha20-generic - don't unnecessarily use atomic walk Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 03/15] crypto: chacha20-generic - add XChaCha20 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 04/15] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 05/15] crypto: chacha - add XChaCha12 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 06/15] crypto: arm/chacha20 - limit the preemption-disabled section Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 07/15] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 12:41   ` Ard Biesheuvel
2018-11-06 12:41     ` Ard Biesheuvel
2018-11-06 12:41     ` Ard Biesheuvel
2018-11-05 23:25 ` [RFC PATCH v3 08/15] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 12:46   ` Ard Biesheuvel
2018-11-06 12:46     ` Ard Biesheuvel
2018-11-06 12:46     ` Ard Biesheuvel
2018-11-05 23:25 ` [RFC PATCH v3 09/15] crypto: arm/chacha - add XChaCha12 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-06 14:28   ` Ard Biesheuvel
2018-11-06 14:28     ` Ard Biesheuvel
2018-11-06 14:28     ` Ard Biesheuvel
2018-11-12 18:58     ` Eric Biggers
2018-11-12 18:58       ` Eric Biggers
2018-11-12 18:58       ` Eric Biggers
2018-11-16  6:02       ` Herbert Xu
2018-11-16  6:02         ` Herbert Xu
2018-11-16  6:02         ` Herbert Xu
2018-11-17  0:17         ` Eric Biggers
2018-11-17  0:17           ` Eric Biggers
2018-11-17  0:17           ` Eric Biggers
2018-11-17  0:30           ` Ard Biesheuvel
2018-11-17  0:30             ` Ard Biesheuvel
2018-11-17  0:30             ` Ard Biesheuvel
2018-11-18 13:46           ` Jason A. Donenfeld
2018-11-18 13:46             ` Jason A. Donenfeld
2018-11-19  5:24             ` [RFC PATCH] zinc chacha20 generic implementation using crypto API code Herbert Xu
2018-11-19  6:13               ` Jason A. Donenfeld
2018-11-19  6:13                 ` Jason A. Donenfeld
2018-11-19  6:22                 ` Herbert Xu
2018-11-19  6:22                   ` Herbert Xu
2018-11-19 22:54                 ` Eric Biggers
2018-11-19 22:54                   ` Eric Biggers
2018-11-19 23:15                   ` Jason A. Donenfeld
2018-11-19 23:15                     ` Jason A. Donenfeld
2018-11-19 23:23                     ` Eric Biggers
2018-11-19 23:23                       ` Eric Biggers
2018-11-19 23:31                       ` Jason A. Donenfeld
2018-11-19 23:31                         ` Jason A. Donenfeld
2018-11-20  3:06                   ` Herbert Xu
2018-11-20  3:06                     ` Herbert Xu
2018-11-20  3:08                     ` Jason A. Donenfeld
2018-11-20  3:08                       ` Jason A. Donenfeld
2018-11-20  6:02               ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Herbert Xu
2018-11-20  6:02                 ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 1/4] crypto: chacha20 - Export chacha20 functions without crypto API Herbert Xu
2018-11-20  6:04                   ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 2/4] zinc: ChaCha20 generic C implementation and selftest Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 3/4] zinc: Add x86 accelerated ChaCha20 Herbert Xu
2018-11-20  6:04                   ` Herbert Xu
2018-11-20  6:04                 ` [v2 PATCH 4/4] zinc: ChaCha20 x86_64 implementation Herbert Xu
2018-11-20 10:32                 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Ard Biesheuvel
2018-11-20 10:32                   ` Ard Biesheuvel
2018-11-20 10:32                   ` Ard Biesheuvel
2018-11-20 14:18                   ` Herbert Xu
2018-11-20 14:18                     ` Herbert Xu
2018-11-20 14:18                     ` Herbert Xu
2018-11-20 16:24                     ` Jason A. Donenfeld
2018-11-20 16:24                       ` Jason A. Donenfeld
2018-11-20 18:51                       ` Theodore Y. Ts'o [this message]
2018-11-20 18:51                         ` Theodore Y. Ts'o
2018-11-21  7:55                       ` Herbert Xu
2018-11-21  7:55                         ` Herbert Xu
2018-11-20 16:18                 ` Jason A. Donenfeld
2018-11-20 16:18                   ` Jason A. Donenfeld
2018-11-21  6:01                   ` Herbert Xu
2018-11-21  6:01                     ` Herbert Xu
2018-11-05 23:25 ` [RFC PATCH v3 11/15] crypto: poly1305 - add Poly1305 core API Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 12/15] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 13/15] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 14/15] crypto: adiantum - add Adiantum support Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-05 23:25 ` [RFC PATCH v3 15/15] fscrypt: " Eric Biggers
2018-11-05 23:25   ` Eric Biggers
2018-11-08  6:47 ` [RFC PATCH v3 00/15] crypto: " Martin Willi
2018-11-08  6:47   ` Martin Willi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181120185154.GB6401@thunk.org \
    --to=tytso@mit.edu \
    --cc=Jason@zx2c4.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ebiggers@kernel.org \
    --cc=gkaiser@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@strongswan.org \
    --cc=paulcrowley@google.com \
    --cc=samuel.c.p.neves@gmail.com \
    --cc=tomer.ashur@esat.kuleuven.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.