[email protected] writes:
> From: Dmitry Eremin-Solenikov <[email protected]>
>
> Add support for GC256B curve ("TLS Supported Groups" registry,
> draft-smyshlyaev-tls12-gost-suites) also known as
> GostR3410-2001-CryptoPro-A and GostR3410-2001-CryptoPro-XchA (RFC 4357).
Thanks. Some comments below:
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -176,6 +176,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \
> ecc-mod.c ecc-mod-inv.c \
> ecc-mod-arith.c ecc-pp1-redc.c ecc-pm1-redc.c \
> ecc-curve25519.c ecc-curve448.c \
> + ecc-gc256b.c \
> ecc-secp192r1.c ecc-secp224r1.c ecc-secp256r1.c \
> ecc-secp384r1.c ecc-secp521r1.c \
> ecc-size.c ecc-j-to-a.c ecc-a-to-j.c \
> @@ -396,12 +397,21 @@ ecc-curve25519.h: eccdata.stamp
> ecc-curve448.h: eccdata.stamp
> ./eccdata$(EXEEXT_FOR_BUILD) curve448 38 6 $(NUMB_BITS) > $@T && mv $@T
> $@
>
> +# Some reasonable choices for 256:
> +# k = 9, c = 6, S = 320, T = 54 ( 45 A + 9 D) 20 KB
> +# k = 11, c = 6, S = 256, T = 55 ( 44 A + 11 D) 16 KB
> +# k = 19, c = 7, S = 256, T = 57 ( 38 A + 19 D) 16 KB
> +# k = 15, c = 6, S = 192, T = 60 ( 45 A + 15 D) 12 KB
> +ecc-gc256b.h: eccdata.stamp
> + ./eccdata$(EXEEXT_FOR_BUILD) gc256b 11 6 $(NUMB_BITS) > $@T && mv $@T $@
> +
These comments and choice copied from secp256r1? I see no reason to do
differently, but one can experiment using the eccparams.c program.
> --- /dev/null
> +++ b/ecc-gc256b.c
> +
> +/* Development of Nettle's ECC support was funded by the .SE Internet Fund.
> */
I don't think there's any reason to add this note to new files. The .SE
project was concluded in 2013.
> +#if HAVE_CONFIG_H
> +# include "config.h"
> +#endif
> +
> +#include <assert.h>
> +
> +#include "ecc.h"
> +#include "ecc-internal.h"
> +
> +#define USE_REDC (ECC_REDC_SIZE != 0)
I think you can do
#define USE_REDC 0
unconditionally, and set the redc function pointer to NULL. (I guess
this applies to a few of the older files too). The only curve where this
conditional definition of USE_REDC seems useful is for secp384r1, where
we'll have ECC_REDC_SIZE != 0 on 32-bit archs but not on 64-bit.
Use of the ecc_pp1_redc and ecc_pm1_redc functions depend on p+1 or p-1
having at least one leading zero limb. A general redc function may be
useful for other less structured primes, but currently, we don't have
any.
> +#include "ecc-gc256b.h"
> +
> +#if ECC_REDC_SIZE > 0
> +# define ecc_gc256b_redc ecc_pp1_redc
> +#elif ECC_REDC_SIZE == 0
> +# define ecc_gc256b_redc NULL
> +#else
> +# error Configuration error
> +#endif
> +
> +static void
> +ecc_gc256b_modp (const struct ecc_modulo *m, mp_limb_t *rp)
> +{
> + mp_size_t mn = m->size;
> + mp_limb_t hi;
> +
> + hi = mpn_addmul_1(rp, rp + mn, mn, 0x269);
> + hi = sec_add_1 (rp, rp, mn, hi * 0x269);
> + hi = sec_add_1 (rp, rp, mn, hi * 0x269);
> + assert(hi == 0);
> +}
The last sec_add_1 could probably be a cnd_add with m->B. But perhaps
sec_add_1 is clearer.
> +const struct ecc_curve *nettle_get_gc256b(void)
> +{
> + return &_nettle_gc256b;
> +}
Would it make sense to add "gost" to this name, in similar position as
"secp" in other curves?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
