[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CZZLKGMM0B9E.7J1CGE8EIGQX@kernel.org>
Date: Thu, 21 Mar 2024 19:17:16 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Stefan Berger" <stefanb@...ux.ibm.com>, <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>, <bbhushan2@...vell.com>
Subject: Re: [PATCH v7 05/13] crypto: ecc - Add nbits field to ecc_curve
structure
On Wed Mar 20, 2024 at 1:47 PM EET, Stefan Berger wrote:
> Add the number of bits a curve has to the ecc_curve definition to be able
> to derive the number of bytes a curve requires for its coordinates from it.
> It also allows one to identify a curve by its particular size. Set the
> number of bits on all curve definitions.
>
> Signed-off-by: Stefan Berger <stefanb@...ux.ibm.com>
> Tested-by: Lukas Wunner <lukas@...ner.de>
> ---
> crypto/ecc_curve_defs.h | 4 ++++
> crypto/ecrdsa_defs.h | 5 +++++
> include/crypto/ecc_curve.h | 2 ++
> 3 files changed, 11 insertions(+)
>
> diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
> index 9719934c9428..ab1ef3d94be5 100644
> --- a/crypto/ecc_curve_defs.h
> +++ b/crypto/ecc_curve_defs.h
> @@ -17,6 +17,7 @@ static u64 nist_p192_b[] = { 0xFEB8DEECC146B9B1ull, 0x0FA7E9AB72243049ull,
> 0x64210519E59C80E7ull };
> static struct ecc_curve nist_p192 = {
> .name = "nist_192",
> + .nbits = 192,
> .g = {
> .x = nist_p192_g_x,
> .y = nist_p192_g_y,
> @@ -43,6 +44,7 @@ static u64 nist_p256_b[] = { 0x3BCE3C3E27D2604Bull, 0x651D06B0CC53B0F6ull,
> 0xB3EBBD55769886BCull, 0x5AC635D8AA3A93E7ull };
> static struct ecc_curve nist_p256 = {
> .name = "nist_256",
> + .nbits = 256,
> .g = {
> .x = nist_p256_g_x,
> .y = nist_p256_g_y,
> @@ -75,6 +77,7 @@ static u64 nist_p384_b[] = { 0x2a85c8edd3ec2aefull, 0xc656398d8a2ed19dull,
> 0x988e056be3f82d19ull, 0xb3312fa7e23ee7e4ull };
> static struct ecc_curve nist_p384 = {
> .name = "nist_384",
> + .nbits = 384,
> .g = {
> .x = nist_p384_g_x,
> .y = nist_p384_g_y,
> @@ -95,6 +98,7 @@ static u64 curve25519_a[] = { 0x000000000001DB41, 0x0000000000000000,
> 0x0000000000000000, 0x0000000000000000 };
> static const struct ecc_curve ecc_25519 = {
> .name = "curve25519",
> + .nbits = 255,
> .g = {
> .x = curve25519_g_x,
> .ndigits = 4,
> diff --git a/crypto/ecrdsa_defs.h b/crypto/ecrdsa_defs.h
> index 0056335b9d03..1c2c2449e331 100644
> --- a/crypto/ecrdsa_defs.h
> +++ b/crypto/ecrdsa_defs.h
> @@ -47,6 +47,7 @@ static u64 cp256a_b[] = {
>
> static struct ecc_curve gost_cp256a = {
> .name = "cp256a",
> + .nbits = 256,
> .g = {
> .x = cp256a_g_x,
> .y = cp256a_g_y,
> @@ -80,6 +81,7 @@ static u64 cp256b_b[] = {
>
> static struct ecc_curve gost_cp256b = {
> .name = "cp256b",
> + .nbits = 256,
> .g = {
> .x = cp256b_g_x,
> .y = cp256b_g_y,
> @@ -117,6 +119,7 @@ static u64 cp256c_b[] = {
>
> static struct ecc_curve gost_cp256c = {
> .name = "cp256c",
> + .nbits = 256,
> .g = {
> .x = cp256c_g_x,
> .y = cp256c_g_y,
> @@ -166,6 +169,7 @@ static u64 tc512a_b[] = {
>
> static struct ecc_curve gost_tc512a = {
> .name = "tc512a",
> + .nbits = 512,
> .g = {
> .x = tc512a_g_x,
> .y = tc512a_g_y,
> @@ -211,6 +215,7 @@ static u64 tc512b_b[] = {
>
> static struct ecc_curve gost_tc512b = {
> .name = "tc512b",
> + .nbits = 512,
> .g = {
> .x = tc512b_g_x,
> .y = tc512b_g_y,
> diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
> index 70964781eb68..63d5754e7614 100644
> --- a/include/crypto/ecc_curve.h
> +++ b/include/crypto/ecc_curve.h
> @@ -23,6 +23,7 @@ struct ecc_point {
> * struct ecc_curve - definition of elliptic curve
> *
> * @name: Short name of the curve.
> + * @nbits: The number of bits of a curve.
> * @g: Generator point of the curve.
> * @p: Prime number, if Barrett's reduction is used for this curve
> * pre-calculated value 'mu' is appended to the @p after ndigits.
> @@ -34,6 +35,7 @@ struct ecc_point {
> */
> struct ecc_curve {
> char *name;
> + unsigned int nbits;
Nit:
Hmm not strongly opionated here but wouldn't it be more consistent to
use u32 here as the types below are also exact bitsize types?
> struct ecc_point g;
> u64 *p;
> u64 *n;
BR, Jarkko
Powered by blists - more mailing lists