вс, 12 янв. 2020 г. в 23:45, Niels Möller nisse@lysator.liu.se:
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 \ 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.
Yes, c&p from secp256r1.
--- /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.
Fine, I'll drop this.
+#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
Fine, that would be even simpler. I was mostly c&p-sting from other ecc curves.
+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.
I don't remember why I chose sec_add_1() instead of cnd_add(). Most probably to be safer.
+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?
I don't think so. Consider the names from "TLS Supported Groups" registry.