linux-kernel - Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384

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: <9ac456d7-a5e1-9e42-5d34-7dc1c70082e0@linux.ibm.com>
Date:   Sat, 6 Mar 2021 18:29:18 -0500
From:   Stefan Berger <stefanb@...ux.ibm.com>
To:     Vitaly Chikunov <vt@...linux.org>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
        davem@...emloft.net, herbert@...dor.apana.org.au,
        dhowells@...hat.com, zohar@...ux.ibm.com,
        linux-kernel@...r.kernel.org, patrick@...terwijk.org,
        linux-integrity@...r.kernel.org,
        Saulo Alessandre <saulo.alessandre@....jus.br>
Subject: Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384

On 3/6/21 2:25 PM, Vitaly Chikunov wrote:
> Stefan,
>
> On Thu, Mar 04, 2021 at 07:51:57PM -0500, Stefan Berger wrote:
>> From: Saulo Alessandre <saulo.alessandre@....jus.br>
>>
>> * crypto/ecc.c
>>    - add vli_mmod_fast_384
>>    - change some routines to pass ecc_curve forward until vli_mmod_fast
>>
>> * crypto/ecc.h
>>    - add ECC_CURVE_NIST_P384_DIGITS
>>    - change ECC_MAX_DIGITS to P384 size
>>
>> Signed-off-by: Saulo Alessandre <saulo.alessandre@....jus.br>
>> Tested-by: Stefan Berger <stefanb@...ux.ibm.com>
>> ---
>>   crypto/ecc.c | 266 +++++++++++++++++++++++++++++++++++++--------------
>>   crypto/ecc.h |   3 +-
>>   2 files changed, 194 insertions(+), 75 deletions(-)
>>
>> diff --git a/crypto/ecc.c b/crypto/ecc.c
>> index f6cef5a7942d..c125576cda6b 100644
>> --- a/crypto/ecc.c
>> +++ b/crypto/ecc.c
>> @@ -778,18 +778,133 @@ static void vli_mmod_fast_256(u64 *result, const u64 *product,
>>   ...
>>   /* Computes result = product % curve_prime for different curve_primes.
>>    *
>>    * Note that curve_primes are distinguished just by heuristic check and
>>    * not by complete conformance check.
>>    */
>>   static bool vli_mmod_fast(u64 *result, u64 *product,
>> -			  const u64 *curve_prime, unsigned int ndigits)
>> +			  const struct ecc_curve *curve)
>>   {
>>   	u64 tmp[2 * ECC_MAX_DIGITS];
>> +	const u64 *curve_prime = curve->p;
>> +	const unsigned int ndigits = curve->g.ndigits;
>>   
>> -	/* Currently, both NIST primes have -1 in lowest qword. */
>> -	if (curve_prime[0] != -1ull) {
>> +	/* Currently, all NIST have name nist_.* */
>> +	if (strncmp(curve->name, "nist_", 5) != 0) {
> I am not sure, but maybe this strncmp should not be optimized somehow,
> since vli_mmod_fast could be called quite frequently. Perhaps by integer
> algo id or even callback?

Should be optimized or should not be? You seem to say both.

The code code here is shared with ecrdsa. The comparison won't go beyond 
a single letter considering the naming of the curves define here:

"cp256a": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L49

"cp256b": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L82

"cp256c": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L119

"tc512a": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecrdsa_defs.h#L168

and here:

"nist_192": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L18

"nist_256": 
https://elixir.bootlin.com/linux/v5.11.3/source/crypto/ecc_curve_defs.h#L45


All the ecrdsa curves were previously evaluating 'curve_prime[0] != 
-1ull', so it doesn't change anything.

   Stefan