diff mbox series

[v6,04/13] crypto: ecdsa - Extend res.x mod n calculation for NIST P521

Message ID 20240312183618.1211745-5-stefanb@linux.vnet.ibm.com (mailing list archive)
State Superseded
Delegated to: Herbert Xu
Headers show
Series Add support for NIST P521 to ecdsa | expand

Commit Message

Stefan Berger March 12, 2024, 6:36 p.m. UTC
From: Stefan Berger <stefanb@linux.ibm.com>

res.x has been calculated by ecc_point_mult_shamir, which uses
'mod curve_prime'. The curve_prime 'p' is typically larger than the
curve_order 'n' and therefore it is possible that p > res.x >= n.

If res.x >= n then res.x mod n can be calculated by iteratively sub-
tracting n from res.x until n > res.x. For NIST P192/256/384 this can be
done in a single subtraction. This can also be done in a single
subtraction for NIST P521.

The mathematical reason why a single subtraction is sufficient is
due to the values of 'p' and 'n' of the NIST curves where the following
holds true:

   note: max(res.x) = p - 1

   max(res.x) - n < n
       p - 1  - n < n
       p - 1      < 2n  => true for the NIST curves

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(-)

Comments

Jarkko Sakkinen March 18, 2024, 8:33 p.m. UTC | #1
On Tue Mar 12, 2024 at 8:36 PM EET, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
>
> res.x has been calculated by ecc_point_mult_shamir, which uses
> 'mod curve_prime'. The curve_prime 'p' is typically larger than the
> curve_order 'n' and therefore it is possible that p > res.x >= n.

The first sentence is an incomplete sentence. A lot of cross-referencing
from e.g. elixir is required to "decipher" this commit message :-)

I do get that math here is complicated but for that matter each commit
message should be written with care, minimizing the require cross-
referencing.

These commit messages are adding extra layer of salt.

>
> If res.x >= n then res.x mod n can be calculated by iteratively sub-
> tracting n from res.x until n > res.x. For NIST P192/256/384 this can be
> done in a single subtraction. This can also be done in a single
> subtraction for NIST P521.
>
> The mathematical reason why a single subtraction is sufficient is
> due to the values of 'p' and 'n' of the NIST curves where the following
> holds true:
>
>    note: max(res.x) = p - 1
>
>    max(res.x) - n < n
>        p - 1  - n < n
>        p - 1      < 2n  => true for the NIST curves
>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> Tested-by: Lukas Wunner <lukas@wunner.de>

What was there to test in this anyway? I see only comment change below.

> ---
>  crypto/ecdsa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
> index 64e1e69d53ba..1814f009f971 100644
> --- a/crypto/ecdsa.c
> +++ b/crypto/ecdsa.c
> @@ -122,7 +122,7 @@ static int _ecdsa_verify(struct ecc_ctx *ctx, const u64 *hash, const u64 *r, con
>  
>  	/* res.x = res.x mod n (if res.x > order) */
>  	if (unlikely(vli_cmp(res.x, curve->n, ndigits) == 1))
> -		/* faster alternative for NIST p384, p256 & p192 */
> +		/* faster alternative for NIST p521, p384, p256 & p192 */
>  		vli_sub(res.x, res.x, curve->n, ndigits);
>  
>  	if (!vli_cmp(res.x, r, ndigits))


BR, Jarkko
Lukas Wunner March 18, 2024, 8:39 p.m. UTC | #2
On Mon, Mar 18, 2024 at 10:33:47PM +0200, Jarkko Sakkinen wrote:
> On Tue Mar 12, 2024 at 8:36 PM EET, Stefan Berger wrote:
> > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > Tested-by: Lukas Wunner <lukas@wunner.de>
> 
> What was there to test in this anyway? I see only comment change below.

The full series was tested, irrespective of the content of the individual
patches.

Thanks,

Lukas
Jarkko Sakkinen March 18, 2024, 10:19 p.m. UTC | #3
On Mon Mar 18, 2024 at 10:39 PM EET, Lukas Wunner wrote:
> On Mon, Mar 18, 2024 at 10:33:47PM +0200, Jarkko Sakkinen wrote:
> > On Tue Mar 12, 2024 at 8:36 PM EET, Stefan Berger wrote:
> > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > > Tested-by: Lukas Wunner <lukas@wunner.de>
> > 
> > What was there to test in this anyway? I see only comment change below.
>
> The full series was tested, irrespective of the content of the individual
> patches.

Tested-by's should be per patch, and in this patch tested-by has no
meaning at all.

In order to determine which patches tested-by is applicable it can
be derived on what was actually tested.

This looks as tested-by was used in place of acked/reviewed-by, which
is not how it should be used.

BR, Jarkko
diff mbox series

Patch

diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
index 64e1e69d53ba..1814f009f971 100644
--- a/crypto/ecdsa.c
+++ b/crypto/ecdsa.c
@@ -122,7 +122,7 @@  static int _ecdsa_verify(struct ecc_ctx *ctx, const u64 *hash, const u64 *r, con
 
 	/* res.x = res.x mod n (if res.x > order) */
 	if (unlikely(vli_cmp(res.x, curve->n, ndigits) == 1))
-		/* faster alternative for NIST p384, p256 & p192 */
+		/* faster alternative for NIST p521, p384, p256 & p192 */
 		vli_sub(res.x, res.x, curve->n, ndigits);
 
 	if (!vli_cmp(res.x, r, ndigits))