Deprecating crypto algorithms in the kernel

Conrad Meyer cem at freebsd.org
Tue May 7 15:55:27 UTC 2019


On Mon, May 6, 2019 at 6:14 PM John Baldwin <jhb at freebsd.org> wrote:
> I have been doing some work off and on to address some of the shortcomings
> in the in-kernel open crypto framework.  … some of the currently supported
> algorithms have known weaknesses or are deprecated in RFCs, by the authors,
> etc.  I would like to take a stab at trimming some of this for FreeBSD 13.
> For an initial proposal, …
>
> This adds runtime deprecation notices in the kernel when using deprecated
> algorithms for IPsec (according to RFC 8221), and Kerberos GSS (RFCs 6649
> and 8429).  It then also adds deprecation notices for a few algorithms in
> GELI.  For GELI, the current patches should refuse to create new volumes
> with these algorithms and warn when mounting an existing volume.
>
> The current optimistic goal would be to merge all the warning back to 11
> and 12 and then remove support for these algorithms outright in 13.0.
> For GELI in particular, I recognize this is somewhat painful as it means
> doing a dump/restore if you've created volumes with affected algorithms.
> OTOH, these algorithms are not the current defaults.

Nor were they ever — the default has always been an aes-based
algorithm since the initial import of GELI in 2005 (r148456).

> Finally, I've added warnings to /dev/crypto to warn if userland tries to
> create new sessions for algorithms that no longer have any non-deprecated
> in-kernel consumers.

We've discussed this offline, but I just wanted to remark on the
public lists that I'm all in favor of removing crufty bad crypto
algorithms, and your chosen list seems to meet that criteria while
being a conservative change.  Please kill 'em.  :-)

Best,
Conrad


More information about the freebsd-arch mailing list