Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #69397

Re: please consider disabling obsolete crypto in 5.10 and later

From Salvatore Bonaccorso <carnil@debian.org>
Newsgroups linux.debian.kernel
Subject Re: please consider disabling obsolete crypto in 5.10 and later
Date 2021-02-01 22:30 +0100
Message-ID <BDOVI-3Hz-7@gated-at.bofh.it> (permalink)
References <BD0YV-5Nt-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Ard,

On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> L.S.,
> 
> This is a request to consider disabling obsolete crypto in 5.10 and
> later Debian builds of the Linux kernel on any architecture.
> 
> We are all familiar with the rigid rules when it comes to not breaking
> userspace by making changes to the kernel, but this rule only takes
> effect when anybody notices, and so I am proposing disabling some code
> downstream before removing it entirely.
> 
> 5.10 introduces a new Kconfig symbol
> 
> CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> 
> which is enabled by default, but depends on support for the AF_ALG
> socket API being enabled. In turn, block ciphers that are obsolete and
> unlikely to be used anywhere have been made to depend on this new
> symbol.
> 
> This means that these obsolete block ciphers will disappear entirely
> when the AF_ALG socket API is omitted, but we can get rid of these
> block ciphers explicitly too, by not setting the new symbol. I.e.,
> adding
> 
> # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> 
> to the kernel configs. Note that Fedora have already done so in release 33 [0]
> 
> The block ciphers in question are RC4, Khazad, SEED, and
> TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> to be used via the socket API (although a change was applied to
> iwd/libell recently to get rid of an occurrence of RC4 - this change
> has already been pulled into bullseye afaik)
> 
> Note that this is not a statement on whether these algorithms are
> secure or not -there is simply no point in carrying and shipping code
> that nobody uses or audits, but which can be autoloaded and exercised
> via an unprivileged interface.

FTR (posteriori), we tried that in
https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
(and is in the 5.10.12-1 upload to unstable).

Regards,
Salvatore

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-01-30 17:10 +0100
  Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-02-01 22:30 +0100
    Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-02-06 00:10 +0100
    Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-02-25 11:40 +0100
      Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-02-25 12:30 +0100
        Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-03-09 18:10 +0100
          Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-03-10 14:40 +0100
            Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-03-10 15:00 +0100

csiph-web