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

Hi all,

Obviously not as a practical suggestion, but just to clarify my
understanding of the issue at hand, would creating a new S-box lookup table
from a verifiably random source completely ameliorate Leo's concerns?
If the S-box was created with no pattern in mind, as stated, then any other
randomly generated lookup table should be equally sound, and would be
immensely unlikely to have this curious structure.
Say we used a distributed randomness beacon to seed a permutation of the
S-box, such that anyone can verify for themselves that the S-box was
generated randomly, would everyone be satisfied that the new version was at
least as secure as the old?

Regards,

Jonathan

On Tue, 6 Aug 2019 at 15:24, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Sorry, I must be confusing something...
>
> On 06/08/2019 15:20, Dmitry Belyavsky wrote:
> > In fact, the reference to 5933 is normative (in part of  DNSSec).
>
> I'm looking at 8624 now and the reference
> to 6986 is in section 7.1 "normative references" [1]
> whereas the reference to 5933 is in 7.2 which
> are the informative references. [2]
>
> An errata that just said to swap those would make
> sense and seems to match what you say below.
>
> Cheers,
> S.
>
> [1] https://tools.ietf.org/html/rfc8624#section-7.1
> [2] https://tools.ietf.org/html/rfc8624#section-7.2
>
> >
> > Then we have reference to the superseding algorithms which personally I
> > tend to treat as informative.
> > It explains why the GOST algorithms have the status MUST NOT for
> > signing/delegation.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>