Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Daniel,

thank you for the link: indeed, the draft GOST R 34.10-2012 has been
already finalized and now is RFC 7091.

In Russia 512-bit curves are not still widely used for everyday document
processing, but a lot of cryptography software and hardware already support
512-bit level – I would say that it is possible to add a novel curve, but
it doesn't seem realistic to change standard (with its constraints) or all
implementations (most of them can't support curves with p>2^{512} or
q>2^{512}).

And at least for these reasons I don't think that our Federal Agency on
Technical Regulating and Metrology could expand possible set for q.

Thank you very much for your attention.

Regards,

Stanislav Smyshlyaev


2015-02-11 18:24 GMT+03:00 Daniel Kahn Gillmor <[e-mail]>:

> On Wed 2015-02-11 02:02:26 -0500, Stanislav V. Smyshlyaev wrote:
>
> > there is a draft of the new Russian digital signature standard GOST R
> > 34.10-2012 in English:
> > https://tools.ietf.org/html/draft-dolmatov-gost34102012-00.
>
> It looks to me like this is now RFC 7091.
>
> > Also the previous standard (there are only two major differences
> > between standards: distinct hash functions and available key sizes
>
> the previous standard was translated in english as RFC 5832, i think.
> here are the sections about parameters restrictions:
>
> https://tools.ietf.org/html/rfc7091#section-5.2
>
> https://tools.ietf.org/html/rfc5832#section-5.2
>
> As i read them, the constraints are in two places:
>
>  a) the fixed-bit-length "Binary vectors" key representations (section
>     5.3) of either exactly 512 bits or 1024 bits, which appear to be
>     concatenations of big-endian values of X and Y coordinates.
>
>  b) equation (9):
>
>    | m = nq, n belongs to Z, n >= 1
>    |                                                                 (9)
>    | 2^254 < q < 2^256 or 2^508 < q < 2^512
>
>
> Constraint (a) does seem to rule out 521-bit values which would cause
> interoperability issues with systems that have adopted this standard,
> but only constraint (b) rules out in-between choices like Goldilocks.
>
> The main change from 2001 to 2012 is the addition of the 512-bit level
> to this standard; how many systems support the 512-bit level with
> arbitrary curves today?  what sort of work needs to be done to enable
> those systems to use a novel curve?  Do implementations actually verify
> equation (9) dynamically when confronted with a new curve, or could
> points from an intermediate curve left-padded with zeros satisfy the
> binary vector representation requirement and move forward with these
> implementations?
>
> Could the Federal Agency on Technical Regulating and Metrology consider
> issuing another revision add a new level (either intermediate or above
> 512) if there was a broader consensus about it?
>
>      --dkg
>