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

Dear Jonathan,

All found properties are only about the particular S-Box (so, yes, "a new
S-box lookup table from a verifiably random source completely ameliorate
Leo's concerns"), but just picking a random S-Box can provide a weak one
(due to known and well-understood attacks, not to some "probably possible"
ones), since there are many properties (to be short, resistance to known
methods of cryptanalysis) that are taken into account when picking an S-Box
for a block cipher.

Best regards,
Stanislav

вт, 6 авг. 2019 г. в 17:32, Jonathan Hoyland <jonathan.hoyland@gmail.com>:

> 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
>>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>