Re: Keys using SHA-1 in the kernel keyring

Uwe Kleine-König <[email protected]> Sun, 23 Mar 2025 18:50:58 +0100
Newsgroups	org.kernel.linux.keys
Message-ID	<rkdw5m3dnwaneqpz7ed4pm6zy6og4xjeiubxpef3melwapkg4w@odcuzqrqxu3q>
Hello Konstantin,

thanks for taking the time to consider the issue.

On Fri, Mar 21, 2025 at 03:20:44PM -0400, Konstantin Ryabitsev wrote:
> On Fri, Feb 07, 2025 at 06:09:40PM +0100, Uwe Kleine-König wrote:
> > Given that fixing is so easy and SHA-1 is broken since 20 years, at
> > least getting the high profile users who regularly sign archives (or
> > keyring commits :-) looks beneficial to me.
> 
> My general concern about this is two-fold:
> 
> 1. What is the actual attack scenario where this could be abused? I know you
>    pointed out that Linus and Greg have sha1 certificates, but they are either

The binding is SHA-1. So the proof that a subkey or a UID belongs to
the master key in question, relies on SHA-1.

>    on UIDs or on their E subkeys, which they don't use for signing.

I discussed this issue a bit in OFTC/#sequoia. It's still not entirely
clear to me if an attacker who manages to create a key matching the
SHA-1 binding of (say) Linus' E subkey, can use it to graft an S subkey
into the E binding. This would be bad as then a
faked-linux-6.27.tar.{xz,sign} pair could look authentic.

Of course it is believed that today nobody can create a subkey matching
a given binding. But this is the scenario that we're considering and
want to protect against. This protection should happen some time
before someone manages to create such keys. So it's not an exact science
to push deprecation of SHA-1 and involves some crystal balling (or
prudence and an early handling).

What is known today is, that SHA-1 is less immune to such an attack than
SHA-256 or SHA-512 which are used today for bindings in new keys. SHA-1
already suffered quite some attacks that decreased the practical safety
of that hash algo a lot from the theoretical optimum for a 160 bit hash.
(https://sha-mbles.github.io/)

So this is about increasing robustness from a level that was considered
OK up to approximately 2005 to one that is considered OK today.

I think the key motivation should be: SHA-1 is unsafe in certain areas.
Switching to something safer is for many applications quite easy. So
instead of arguing that in this case SHA-1 is fine (which might well be
right today), just switch to a safer hash. This way you simplify the
overall situation and can concentrate on the situations where it's
harder to replace SHA-1 (or kernel development or something else you
care about). That is the approach that NIST is taking:
https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps

>    Both of
>    them have [SC] keys, so I don't believe the following case wouldn't really
>    apply:
> 
>    > (You could even argue that the old archives should get resigned, but I'd
>    > already be happy if future signatures will be fixed.)
> 
>    Since they aren't signed by subkeys but by main [SC] keys, I don't believe
>    anything would be gained by resigning the old archives.

Ack. That suggestion was non-sense and wouldn't improve security.

> 2. The second concern is the fact that we're changing keys for Linus and Greg,
>    and just the fact that their keys will have obscure changes may create a
>    negative impact of its own from the social engineering perspective. If
>    someone sees that Linus's key has changed, but after they pull in the
>    update there is no visible change to the key in the keyring is going to
>    cause confusion.

I agree this could create confusion. But it could also create awareness
that there are many additional PGP keys out there that are worth
updating even though the details are not available when just looking at
the output of `gpg --list-sigs
ABAF11C65A2970B130ABE3C479BE3E4300411886`.

Note that a user of e.g. `sq inspect
--cert=ABAF11C65A2970B130ABE3C479BE3E4300411886` will see the
difference.

> 3. Third concern is more of an aside that Linus hates PGP and getting him to
>    do anything with his keys is usually an endeavour. :)

One theory is that he doesn't hate PGP, but the GnuPG implementation of
it. Sequoia isn't without a learning curve, but I know several people
who think -- after grokking these initial hurdles -- Sequoia makes
sense.  For GnuPG the usual feeling is "I don't think I will ever
understand PGP". Might just be my bubble..?!

Best regards
Uwe
signature.asc (application/pgp-signature, 488 B)