Re: [Cfrg] On the (non-)randomness of the S-box of Streebog and Kuznyechik

[Stephen Farrell <[e-mail]>]

Hiya,

On 05/08/2019 16:35, Leo Perrin wrote:
> Because of these observations, I insist that the designers of these
> algorithms have provided cryptanalysts with misleading information.
> There cannot be any good reason for this, which is why I think these
> algorithms cannot be trusted, and thus that RFC 6986 and 7801 should
> be deprecated.
Actually, this might need to be (at least partly) handled outside
CFRG by the IETF, as there is at least one standards track DNSSEC
RFC (RFC8624 [1]) with a normative reference to 6986.

There are also other documents with references to these RFCs, you
can see which documents reference 6986 at [2] and 7801 at [3]. (I
didn't check any of the others of those out myself though.)

However, the DNSSEC situation may be less bad than it seems, as
8624 says:

"
   GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in
   [RFC6986].  GOST R 34.11-2012 has not been standardized for use in
   DNSSEC.
"

Does the structure you've discovered also exist in GOST R 34.11-94?

If it did, then there'd be a good case (IMO) to further deprecate use
of DNSSEC hash function #3, but if not, then perhaps the correct thing
is some kind of erratum to the effect that 6986 really ought not be
a normative reference in 8624 but rather RFC5831 ought be what's
referenced.

There is a similar statement about the related signature algorithm
(code point #12) defined in RFC7091 that also has a normative
reference to 6986.

Complicating matters a bit more, both code points are defined
with a "MUST NOT" implementation recommendation (which I don't
really understand;-) in RFC8624.

In general I would support CFRG deprecating any algorithms for
which there is significant doubt. I have not myself verified that
the structure Leo has found is real, but assuming it is then IMO
that'd be sufficient reason to deprecate these algorithms. But, I
think deprecating algorithms ought be done taking into account
existing deployments as well as the severity of the issue with
the algorithm. I'm not familiar with how widely these algorithms
are deployed.

For Leo: if you think these algorithms ought be deprecated then
writing an I-D to that effect would be what you'd want to do. If
you wanted help from someone more familiar with IETF/IRTF process
crap, I'd be happy to try help as needed.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc8624
[2] https://datatracker.ietf.org/doc/rfc6986/referencedby/
[3] https://datatracker.ietf.org/doc/rfc7801/referencedby/