From: "Theodore Ts'o" <tytso@mit.edu>
To: Joachim Vandersmissen <git@jvdsn.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
dhowells@redhat.com, linux-crypto@vger.kernel.org
Subject: Re: SHAKE256 support
Date: Thu, 18 Sep 2025 20:05:55 -0400 [thread overview]
Message-ID: <20250919000555.GD416742@mit.edu> (raw)
In-Reply-To: <783702f5-4128-4299-996b-fe95efb49a4b@jvdsn.com>
On Wed, Sep 17, 2025 at 10:53:12PM -0500, Joachim Vandersmissen wrote:
> I'm not too familiar with the history of lib/crypto/, but I have noticed
> over the past months that there has been a noticeable shift to moving
> in-kernel users from the kernel crypto API to the library APIs. While this
> seems to be an overall improvement, it does make FIPS compliance more
> challenging. If the kernel crypto API is the only user of lib/crypto/, it is
> possible to make an argument that the testmgr.c self-tests cover the
> lib/crypto/ implementations (since those would be called at some point).
> However since other code is now calling lib/crypto/ directly, that
> assumption may no longer hold.
In general, customers who lookng for FIPS compliance need it for some
specific application --- for example, encrypting medical records, or
credit card numbers, or while establishing TLS connections, etc. In
my experience, customers do *not* require that all use of encryption
in the kernel, or in various userspce applications, must be FIPS
compliance.
So while some in-kernel users are switching to library API's, it might
not matter. Heck, in some cases the only thing that might matter is
the OpenSSL userspace library.
I'll also note that if you need formal FIPS certification, what the
FIPS labs certify is a specific binary artifact. If the binary needs
to change --- say, to fix a critcial high-severity CVE security
vulnerability, fixing the security vulnerability might end up breaking
the FIPS certification, requiring payment of more $$$ to the FIPS
certification lab. Which is a rather unfortunate incentive about
whether or not security vulnerabilities should be fixed.
So I personally consider FIPS certification to be over-priced security
theater. If it's needed because the customer needs it, and hopefully,
is willing to pay $$$ for it, my advice is to do the minimal needed so
you can get the magic checkbox so you can sell into the government
market or whaever. FIPS compliance for its own sake is a waste of
time and effort, and in my opinion, the tax should be paid only by the
customers who want the silly thing.
Cheers,
- Ted
prev parent reply other threads:[~2025-09-19 0:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 20:51 SHAKE256 support David Howells
2025-09-15 21:00 ` David Howells
2025-09-15 22:07 ` Eric Biggers
2025-09-17 16:20 ` David Howells
2025-09-17 18:48 ` Eric Biggers
2025-09-17 19:11 ` David Howells
2025-09-17 19:28 ` Eric Biggers
2025-09-18 3:53 ` Joachim Vandersmissen
2025-09-18 4:17 ` Eric Biggers
2025-09-18 13:37 ` Simo Sorce
2025-09-18 15:53 ` Eric Biggers
2025-09-19 0:05 ` Theodore Ts'o [this message]
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=20250919000555.GD416742@mit.edu \
--to=tytso@mit.edu \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=git@jvdsn.com \
--cc=linux-crypto@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox