linux-kernel - Re: [PATCH v6 06/13] crypto: ecc - Implement vli_mmod_fast

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: <4151f2f0-aa92-480d-aad5-2bf4333b4265@linux.ibm.com>
Date: Mon, 18 Mar 2024 14:38:32 -0400
From: Stefan Berger <stefanb@...ux.ibm.com>
To: Bharat Bhushan <bbhushan2@...vell.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "saulo.alessandre@....jus.br" <saulo.alessandre@....jus.br>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "jarkko@...nel.org" <jarkko@...nel.org>
Subject: Re:  [PATCH v6 06/13] crypto: ecc - Implement vli_mmod_fast_521 for NIST
 p521



On 3/18/24 01:47, Bharat Bhushan wrote:
> 
> 
>> -----Original Message-----
>> From: Stefan Berger <stefanb@...ux.vnet.ibm.com>
>> Sent: Wednesday, March 13, 2024 12:06 AM
>> To: keyrings@...r.kernel.org; linux-crypto@...r.kernel.org;
>> herbert@...dor.apana.org.au; davem@...emloft.net
>> Cc: linux-kernel@...r.kernel.org; saulo.alessandre@....jus.br;
>> lukas@...ner.de; Bharat Bhushan <bbhushan2@...vell.com>;
>> jarkko@...nel.org; Stefan Berger <stefanb@...ux.ibm.com>
>> Subject: [EXTERNAL] [PATCH v6 06/13] crypto: ecc - Implement
>> vli_mmod_fast_521 for NIST p521
>>
>> Prioritize security for external emails: Confirm sender and content safety
>> before clicking links or opening attachments
>>
>> ----------------------------------------------------------------------
>> From: Stefan Berger <stefanb@...ux.ibm.com>
>>
>> Implement vli_mmod_fast_521 following the description for how to calculate
>> the modulus for NIST P521 in the NIST publication "Recommendations for
>> Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters"
>> section G.1.4.
>>
>> NIST p521 requires 9 64bit digits, so increase the ECC_MAX_DIGITS so that
>> arrays fit the larger numbers.
>>
>> Signed-off-by: Stefan Berger <stefanb@...ux.ibm.com>
>> ---
>>   crypto/ecc.c                  | 25 +++++++++++++++++++++++++
>>   include/crypto/internal/ecc.h |  3 ++-
>>   2 files changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/crypto/ecc.c b/crypto/ecc.c index 415a2f4e7291..99d41887c005
>> 100644
>> --- a/crypto/ecc.c
>> +++ b/crypto/ecc.c
>> @@ -902,6 +902,28 @@ static void vli_mmod_fast_384(u64 *result, const
>> u64 *product,  #undef AND64H  #undef AND64L
>>
>> +/*
>> + * Computes result = product % curve_prime
>> + * from "Recommendations for Discrete Logarithm-Based Cryptography:
>> + *       Elliptic Curve Domain Parameters" section G.1.4
>> + */
>> +static void vli_mmod_fast_521(u64 *result, const u64 *product,
>> +			      const u64 *curve_prime, u64 *tmp) {
>> +	const unsigned int ndigits = ECC_CURVE_NIST_P521_DIGITS;
>> +	size_t i;
>> +
>> +	/* Initialize result with lowest 521 bits from product */
>> +	vli_set(result, product, ndigits);
>> +	result[8] &= 0x1ff;
>> +
>> +	for (i = 0; i < ndigits; i++)
>> +		tmp[i] = (product[8 + i] >> 9) | (product[9 + i] << 55);
>> +	tmp[8] &= 0x1ff;
> 
> Can we get away from this hardcoding, like 9, 55, 0x1ff etc.
> Or at least add comment about these.
> 
>> +
>> +	vli_mod_add(result, result, tmp, curve_prime, ndigits); }
>> +
>>   /* Computes result = product % curve_prime for different curve_primes.
>>    *
>>    * Note that curve_primes are distinguished just by heuristic check and @@ -
>> 941,6 +963,9 @@ static bool vli_mmod_fast(u64 *result, u64 *product,
>>   	case ECC_CURVE_NIST_P384_DIGITS:
>>   		vli_mmod_fast_384(result, product, curve_prime, tmp);
>>   		break;
>> +	case ECC_CURVE_NIST_P521_DIGITS:
>> +		vli_mmod_fast_521(result, product, curve_prime, tmp);
>> +		break;
>>   	default:
>>   		pr_err_ratelimited("ecc: unsupported digits size!\n");
>>   		return false;
>> diff --git a/include/crypto/internal/ecc.h b/include/crypto/internal/ecc.h index
>> ab722a8986b7..4e2f5f938e91 100644
>> --- a/include/crypto/internal/ecc.h
>> +++ b/include/crypto/internal/ecc.h
>> @@ -33,7 +33,8 @@
>>   #define ECC_CURVE_NIST_P192_DIGITS  3
>>   #define ECC_CURVE_NIST_P256_DIGITS  4
>>   #define ECC_CURVE_NIST_P384_DIGITS  6
>> -#define ECC_MAX_DIGITS              (512 / 64) /* due to ecrdsa */
>> +#define ECC_CURVE_NIST_P521_DIGITS  9
> 
> Maybe these can be defined as:
> #define ECC_CURVE_NIST_P521_DIGITS  (DIV_ROUND_UP(521, 64) /* NIST P521 */)

I think for NIST P521 9 can be pre-calculated. It will not change 
anymore in the future.

> 
>> +#define ECC_MAX_DIGITS              DIV_ROUND_UP(521, 64) /* NIST P521 */
> 
> /* NIST_P521 is max digits */
> #define ECC_MAX_DIGITS              ECC_CURVE_ _DIGITS

In this case I think the DIV_ROUND_UP() along with the comment shows 
that it needs to be updated if ever a larger curve comes along.

> 
> Thanks
> -Bharat
> 
>>
>>   #define ECC_DIGITS_TO_BYTES_SHIFT 3
>>
>> --
>> 2.43.0
>