вс, 12 янв. 2020 г. в 23:45, Niels Möller <[email protected]>:
>
> [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.
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.
--
With best wishes
Dmitry
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
