[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <711de58c-4f7c-4643-4b8b-6af98ed1a7bc@huawei.com>
Date: Wed, 16 Dec 2020 10:39:38 +0800
From: yumeng <yumeng18@...wei.com>
To: Stephan Mueller <smueller@...onox.de>
CC: <linux-crypto@...r.kernel.org>, <xuzaibo@...wei.com>,
<wangzhou1@...ilicon.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
> Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
>>
>> +/* size in bytes of the n prime */
>> +#define HPRE_ECC_NIST_P128_N_SIZE 16
>
> Do we truly need P-128? Besides, I do not see that curve being defined in
> contemporary cipher specs.
>
>> +#define HPRE_ECC_NIST_P192_N_SIZE 24
>> +#define HPRE_ECC_NIST_P224_N_SIZE 28
>> +#define HPRE_ECC_NIST_P256_N_SIZE 32
>> +#define HPRE_ECC_NIST_P320_N_SIZE 40
>
> Do we truly need P-320? Besides, I do not see that curve being defined in
> contemporary cipher specs.
Yes, in rfc 5903, only P-256, P-384 and P-521 is defined, but in
'rfc5639' and "SEC 2: Recommended Elliptic Curve Domain Parameters",
other curves like P-128, P-192, P-224, and P-320 curve parameters are
found, and they are used in 'openssl';
How about your idea?
Thanks,
>> +#define HPRE_ECC_NIST_P384_N_SIZE 48
>> +#define HPRE_ECC_NIST_P521_N_SIZE 66
>> +
>> +/* size in bytes */
>> +#define HPRE_ECC_HW256_KSZ_B 32
>> +#define HPRE_ECC_HW384_KSZ_B 48
>> +#define HPRE_ECC_HW576_KSZ_B 72
>> +
>> +#define HPRE_ECDH_MAX_SZ HPRE_ECC_HW576_KSZ_B]
>
> Ciao
> Stephan
>
> .
>
Powered by blists - more mailing lists