linux-kernel - Re: [PATCH v6 03/13] crypto: ecdsa - Adjust tests on length of key parameters

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]

Date: Tue, 19 Mar 2024 00:25:22 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Lukas Wunner" <lukas@...ner.de>
Cc: "Stefan Berger" <stefanb@...ux.vnet.ibm.com>,
 <keyrings@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
 <herbert@...dor.apana.org.au>, <davem@...emloft.net>,
 <linux-kernel@...r.kernel.org>, <saulo.alessandre@....jus.br>,
 <bbhushan2@...vell.com>, "Stefan Berger" <stefanb@...ux.ibm.com>
Subject: Re: [PATCH v6 03/13] crypto: ecdsa - Adjust tests on length of key
 parameters

On Mon Mar 18, 2024 at 10:32 PM EET, Lukas Wunner wrote:
> On Mon, Mar 18, 2024 at 10:25:26PM +0200, Jarkko Sakkinen wrote:
> > On Tue Mar 12, 2024 at 8:36 PM EET, Stefan Berger wrote:
> > > From: Stefan Berger <stefanb@...ux.ibm.com>
> > >
> > > In preparation for support of NIST P521, adjust the basic tests on the
> > > length of the provided key parameters to only ensure that the length of the
> > > x plus y coordinates parameter array is not an odd number and that each
> > > coordinate fits into an array of 'ndigits' digits. Mathematical tests on
> > > the key's parameters are then done in ecc_is_pubkey_valid_full rejecting
> > > invalid keys.
> > >
> > > The change is necessary since NIST P521 keys do not have keys with
> > > coordinates that each fully require 'full' digits (= u64), unlike
> > > NIST P192/256/384 that all require multiple 'full' digits.
> > 
> > This sentence is not really comprehendable English sentence. Can you
> > just write the rationale in understandable form?
> > 
> > "fully require full digits (= u64)" is something totally alien to me
> > tbh.
>
> It is proper English, but requires an understanding of how large integers
> are handled by crypto/ecdsa.c:  They're a sequence of u64.  For P192, P256
> and P384 all u64 in the sequence are used to their full extent because the
> key size is divisable by 64.  That's not the case for P521, where the most
> significant u64 is not fully used (only 2 out of 8 bytes are used).

This would be a great extension to the current commit message.

My point here is that:

1. I obviously acknowledge that not all math etc. related to a crypto
   standard can be explained in a commit message.
2. That said, they should be more verbose than usualy commit messages
   to be as easy to follow as possible, given the complexity of topic.

Here the topic is fairly complex but most of commit messages are written
without much focus on the background story. In this type of patch set
even having some redundancy in the commit messages is favorable so that
they are as easy to understand as possible.

Actually just as code changes they are quite simple but why they are
made is the complex topic, which means that commit messages are even
more important. This motivation comes from e.g. when these need to be
backtracked at some point when bisecting a bug and whatnot.

> Thanks,
>
> Lukas

BR, Jarkko