| Message ID | 20240312183618.1211745-4-stefanb@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add support for NIST P521 to ecdsa | expand |
On Tue Mar 12, 2024 at 8:36 PM EET, Stefan Berger wrote: > From: Stefan Berger <stefanb@linux.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. > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> > Tested-by: Lukas Wunner <lukas@wunner.de> > --- > crypto/ecdsa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c > index 6653dec17327..64e1e69d53ba 100644 > --- a/crypto/ecdsa.c > +++ b/crypto/ecdsa.c > @@ -230,7 +230,7 @@ static int ecdsa_set_pub_key(struct crypto_akcipher *tfm, const void *key, unsig > if (ret < 0) > return ret; > > - if (keylen < 1 || (((keylen - 1) >> 1) % sizeof(u64)) != 0) > + if (keylen < 1 || ((keylen - 1) & 1) != 0) > return -EINVAL; > /* we only accept uncompressed format indicated by '4' */ > if (d[0] != 4) BR, Jarkko
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@linux.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). Thanks, Lukas
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@linux.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
diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c index 6653dec17327..64e1e69d53ba 100644 --- a/crypto/ecdsa.c +++ b/crypto/ecdsa.c @@ -230,7 +230,7 @@ static int ecdsa_set_pub_key(struct crypto_akcipher *tfm, const void *key, unsig if (ret < 0) return ret; - if (keylen < 1 || (((keylen - 1) >> 1) % sizeof(u64)) != 0) + if (keylen < 1 || ((keylen - 1) & 1) != 0) return -EINVAL; /* we only accept uncompressed format indicated by '4' */ if (d[0] != 4)