linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	davem@davemloft.net, herbert@gondor.apana.org.au,
	dhowells@redhat.com, zohar@linux.ibm.com,
	linux-kernel@vger.kernel.org, patrick@puiterwijk.org,
	linux-integrity@vger.kernel.org,
	Saulo Alessandre <saulo.alessandre@tse.jus.br>,
	Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [PATCH v10 3/9] crypto: Add math to support fast NIST P384
Date: Sat, 6 Mar 2021 22:25:53 +0300	[thread overview]
Message-ID: <20210306192553.lxy5w262g2vs2hvv@altlinux.org> (raw)
In-Reply-To: <20210305005203.3547587-4-stefanb@linux.vnet.ibm.com>

Stefan,

On Thu, Mar 04, 2021 at 07:51:57PM -0500, Stefan Berger wrote:
> From: Saulo Alessandre <saulo.alessandre@tse.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@tse.jus.br>
> Tested-by: Stefan Berger <stefanb@linux.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?

Thanks,

>  		/* Try to handle Pseudo-Marsenne primes. */
>  		if (curve_prime[ndigits - 1] == -1ull) {
>  			vli_mmod_special(result, product, curve_prime,
> @@ -812,6 +927,9 @@ static bool vli_mmod_fast(u64 *result, u64 *product,
>  	case 4:
>  		vli_mmod_fast_256(result, product, curve_prime, tmp);
>  		break;
> +	case 6:
> +		vli_mmod_fast_384(result, product, curve_prime, tmp);
> +		break;
>  	default:
>  		pr_err_ratelimited("ecc: unsupported digits size!\n");
>  		return false;
> @@ -835,22 +953,22 @@ EXPORT_SYMBOL(vli_mod_mult_slow);
>  
>  /* Computes result = (left * right) % curve_prime. */
>  static void vli_mod_mult_fast(u64 *result, const u64 *left, const u64 *right,
> -			      const u64 *curve_prime, unsigned int ndigits)
> +			      const struct ecc_curve *curve)
>  {
>  	u64 product[2 * ECC_MAX_DIGITS];
>  
> -	vli_mult(product, left, right, ndigits);
> -	vli_mmod_fast(result, product, curve_prime, ndigits);
> +	vli_mult(product, left, right, curve->g.ndigits);
> +	vli_mmod_fast(result, product, curve);
>  }
>  
>  /* Computes result = left^2 % curve_prime. */
>  static void vli_mod_square_fast(u64 *result, const u64 *left,
> -				const u64 *curve_prime, unsigned int ndigits)
> +				const struct ecc_curve *curve)
>  {
>  	u64 product[2 * ECC_MAX_DIGITS];
>  
> -	vli_square(product, left, ndigits);
> -	vli_mmod_fast(result, product, curve_prime, ndigits);
> +	vli_square(product, left, curve->g.ndigits);
> +	vli_mmod_fast(result, product, curve);
>  }
>  
>  #define EVEN(vli) (!(vli[0] & 1))

  parent reply	other threads:[~2021-03-06 19:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  0:51 [PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys Stefan Berger
2021-03-05  0:51 ` [PATCH v10 1/9] crypto: Add support for ECDSA signature verification Stefan Berger
2021-03-05 17:05   ` Jarkko Sakkinen
2021-03-05 17:58     ` Vitaly Chikunov
2021-03-05 19:46     ` Vitaly Chikunov
2021-03-05 22:15       ` Stefan Berger
2021-03-05  0:51 ` [PATCH v10 2/9] crypto: Add NIST P384 curve parameters Stefan Berger
2021-03-05 17:08   ` Jarkko Sakkinen
2021-03-05  0:51 ` [PATCH v10 3/9] crypto: Add math to support fast NIST P384 Stefan Berger
2021-03-05 17:09   ` Jarkko Sakkinen
2021-03-06 19:25   ` Vitaly Chikunov [this message]
2021-03-06 23:29     ` Stefan Berger
2021-03-07  0:03       ` Vitaly Chikunov
2021-03-07  1:21         ` Stefan Berger
2021-03-05  0:51 ` [PATCH v10 4/9] ecdsa: Register NIST P384 and extend test suite Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen
2021-03-05 18:27     ` Stefan Berger
2021-03-05  0:51 ` [PATCH v10 5/9] x509: Detect sm2 keys by their parameters OID Stefan Berger
2021-03-05  7:39   ` Tianjia Zhang
2021-03-05 17:16   ` Jarkko Sakkinen
2021-03-05 18:02     ` Stefan Berger
2021-03-05  0:52 ` [PATCH v10 6/9] x509: Add support for parsing x509 certs with ECDSA keys Stefan Berger
2021-03-05 17:07   ` Jarkko Sakkinen
2021-03-05  0:52 ` [PATCH v10 7/9] ima: Support EC keys for signature verification Stefan Berger
2021-03-05  0:52 ` [PATCH v10 8/9] x509: Add OID for NIST P384 and extend parser for it Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen
2021-03-05  0:52 ` [PATCH v10 9/9] certs: Add support for using elliptic curve keys for signing modules Stefan Berger
2021-03-05 17:07   ` Jarkko Sakkinen
2021-03-05  0:53 ` [PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys Stefan Berger
2021-03-05 17:10   ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210306192553.lxy5w262g2vs2hvv@altlinux.org \
    --to=vt@altlinux.org \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrick@puiterwijk.org \
    --cc=saulo.alessandre@tse.jus.br \
    --cc=stefanb@linux.ibm.com \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).