linux-kernel - Re: [PATCH] crypto: mscode_parser: remove sha224 authenticode support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXFVPnowdREEjVREy=KKY12nZUp58qL2b_u97=bOTz0wgA@mail.gmail.com>
Date:   Wed, 11 Oct 2023 10:42:18 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Dimitri John Ledkov <dimitri.ledkov@...onical.com>
Cc:     David Howells <dhowells@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: mscode_parser: remove sha224 authenticode support

On Tue, 10 Oct 2023 at 23:25, Dimitri John Ledkov
<dimitri.ledkov@...onical.com> wrote:
>
> It is possible to stand up own certificates and sign PE-COFF binaries
> using SHA-224. However it never became popular or needed since it has
> similar costs as SHA-256. Windows Authenticode infrastructure never
> had support for SHA-224, and all secureboot keys used fro linux

fro

> vmlinuz have always been using at least SHA-256.
>
> Given the point of mscode_parser is to support interoperatiblity with

interoperatibility

> typical de-facto hashes, remove support for SHA-224 to avoid
> posibility

the possibility

> of creating interoperatibility

interoperability

> issues with rhboot/shim,
> grub, and non-linux systems trying to sign or verify vmlinux.
>
> SHA-224 itself is not removed from the kernel, as it is truncated
> SHA-256. If requested I can write patches to remove SHA-224 support
> across all of the drivers.
>

We can stop using it but we cannot remove it.

As you say, it is just SHA-256 with a different initial state and a
truncated hash, so removing support entirely achieves very little. And
there are plenty of other algorithms we'd be happy to remove first if
we were only sure that nobody was relying on them. (Note that AF_ALG
supports AEAD so someone somewhere could be using the kernel's sha224
from user space)

> Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@...onical.com>

Acked-by: Ard Biesheuvel <ardb@...nel.org>

> ---
>  crypto/asymmetric_keys/mscode_parser.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/crypto/asymmetric_keys/mscode_parser.c b/crypto/asymmetric_keys/mscode_parser.c
> index 6416bded0e..855cbc46a9 100644
> --- a/crypto/asymmetric_keys/mscode_parser.c
> +++ b/crypto/asymmetric_keys/mscode_parser.c
> @@ -84,9 +84,6 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,
>         case OID_sha512:
>                 ctx->digest_algo = "sha512";
>                 break;
> -       case OID_sha224:
> -               ctx->digest_algo = "sha224";
> -               break;
>
>         case OID__NR:
>                 sprint_oid(value, vlen, buffer, sizeof(buffer));
> --
> 2.34.1
>