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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Tue, 06 August 2019 14:31 UTC

Return-Path: <jonathan.hoyland@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C311200B9 for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 07:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THvItrCjlYeo for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 07:31:50 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C48120041 for <cfrg@irtf.org>; Tue, 6 Aug 2019 07:31:50 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id k9so58407303vso.5 for <cfrg@irtf.org>; Tue, 06 Aug 2019 07:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uy+W8s7zCs7HjiRlR3wjSuihKPEzUs4Qpft7h/jSpgs=; b=dy7WchwLFMWfsaljXGz/bEg/mmGIc4C39xFjzRdnH1YPL3F2BBhtfELnhccM+tDc6H HwZKwFJTr7hp9tErF8dCc+yNjnrTTmCJDH3cg2XZR4VorTNqbxlsC3QGpYj1efihRK+n D94MCaINvRTbDi4RbM+MUp2QIZebuEOgahGqOOAGRtNOL4w7L2ztUUSAik7FHrZxfs0Q nm3COlaSw5DdyY95ZwJmNdsg8sU8nbuTmck8GpuIifNERJNSDQ8idzK4b/e90Kthbt5p eCGC+rx88YytbZL9hS3px+t8VbRcbXoAMHj3MupvmZml5mSMCtRgQI6BrFv4Wb+EiyZE pzIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uy+W8s7zCs7HjiRlR3wjSuihKPEzUs4Qpft7h/jSpgs=; b=ZZ4C9ElmWX2+8m7YrI+H6UeEzsB/+qQi2srxx6GejP+OqQWISVHMGfWEfgIzIvEhjy lPyHi1fK+8kAmkPZTS/hKmKWzY5F6KUZAj6nfWeHSWjanuAuhXot2rAORnfSjBdLw+Ee oDwFYd2FUXFHNvp4tnnu5A1xvRxQYUD2cULTJe+MJWwK27jsg3AVcXMIlf6UJFgtkt08 jE7pE9lo2fKKYFDcz27kK5d8qdtr6upMjGI06Z2NWqUcCcJPJS1tn80kQ+OhUXIEcUbM dsQFdSqZJNfYuVgpgg6tgZIp5Yo57dF2REwDPWM8Jx0PFKEXJ0lb8NcKOsYe8/wJ84nF 0ylw==
X-Gm-Message-State: APjAAAXmL8x7TCDpDnY9AX9NAxdSFJTS1y/qgffYBk8gZ3v+GOUCYeZu HX9lIn7AAb16K+ZbNv+H6hFvYn7hIHmS+CSMQVElcEcT1+Q=
X-Google-Smtp-Source: APXvYqyvqsCgm4bDfSqhT9jBv16AiY2xAATEERgaKEbisTTffOMblKBU8wM2Rgy3nX4KYspZSyq+0skb5ho7vMQHeaE=
X-Received: by 2002:a05:6102:8c:: with SMTP id t12mr2607529vsp.143.1565101909602; Tue, 06 Aug 2019 07:31:49 -0700 (PDT)
MIME-Version: 1.0
References: <1327417226.25659372.1565019306532.JavaMail.zimbra@inria.fr> <CADqLbz+2dbvxdaGKp_3XMprp4XMxDK=B=1GKCLmxkjThX9kPYg@mail.gmail.com> <CAMr0u6kGAPRoS70uqqOPJzv30tBR0pgMKLSrBO0eksWrB5Pi8w@mail.gmail.com> <cb745eda-cbc7-b35a-d3fe-6cdecf3cfd05@cs.tcd.ie> <CAMr0u6kWweGAaF3RoLNXkt3Np6xyfB_HxT6P1LLGFPqmVETqvg@mail.gmail.com> <CADqLbzK-CjdLoOy2YTbzYjiEo_pofCY8u5oXEJsC5b-ofApFmQ@mail.gmail.com> <0f69f440-1e83-67f0-3538-12f3a566bc85@cs.tcd.ie> <CADqLbzLC=+ACxZoiiWtuAAPXgqoqwS_bwKgtg1SCUzsHtc-YcQ@mail.gmail.com> <424dc6e8-9617-9469-ea49-de466bff7258@cs.tcd.ie>
In-Reply-To: <424dc6e8-9617-9469-ea49-de466bff7258@cs.tcd.ie>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Tue, 6 Aug 2019 15:31:37 +0100
Message-ID: <CACykbs0PQDqyKUbJ9XZ-=Oksp=or8CCkC70CqBue_wXFApm3AQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Dmitry Belyavsky <beldmit@gmail.com>, cfrg <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000005bfce0058f73afca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7Js6X9gUhWDJNjlf8qlUzGVwWX0>
Subject: Re: [Cfrg] On the (non-)randomness of the S-box of Streebog and Kuznyechik
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 14:31:53 -0000

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
>