dbaryshkov@gmail.com writes:
From: Dmitry Eremin-Solenikov dbaryshkov@gmail.com
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 \@@ -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