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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 06 August 2019 13:56 UTC

Return-Path: <smyshsv@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 B332B120324 for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 06:56:59 -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 lxjaIAvNXrNz for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 06:56:57 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 F12061201E2 for <cfrg@irtf.org>; Tue, 6 Aug 2019 06:56:56 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id h10so10865944ljg.0 for <cfrg@irtf.org>; Tue, 06 Aug 2019 06:56:56 -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=rMjzFJu1TNKGTPZfBXNGeo4J1RLXNX7hhUEngGFWgfU=; b=bkr9EPIxK8iUWIqiu3azgDqw/qWjcByg5FdeIfXJot8di0IfVVT8yk25y3c7PD2pQd lYIaN/Y58KvKtDzyFKDIwpOacsR1zXctTVF9odGhrsceVrNv35a2383b4/kHJPyK15bC jqTaO8RqvCNyIfuejIKorco4RU3lOIpRSjPgqabG3zs/QK8hWzpkRIp6Cjy0mWmv3f3h YRhHWwP2a8Nz3KcRPkBOqUbhgfGdv4LwHsfbRFRnI7O/sGvAUzW8LoXhHDTjmUa2/ufN QlGtvpigGJlN6MIiZLltt/pMiq/pBmjR65OVaycyjbZEDNP5YesCvPhr0Sf989dplxIH C7bQ==
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=rMjzFJu1TNKGTPZfBXNGeo4J1RLXNX7hhUEngGFWgfU=; b=B1FL5mNrAgIHHv/OBpAI7IrWPG7ZHULih4ViI9ORTChin+3/k6d5BNpxJbnKVm4wiI 7hjaXOCrM4hBCiwHbu5AWpiEEx935hBfa88M0Ig7CAwM2JGV+Dk16rNJZMfLmdUwU4cQ UHNEuJOFFFLzVjNXlDmdLxAhEB+Dc3U4v61ex9KIHCoj4Nj4bT33kMocLVQn3P/+xKk/ soJ9Ja1cnmBIB/rMpz1wDcexvxKThd7drJD7Eu2wIRHy1uNc/oYBCmNkVTcmUY8b0Fve +HpgG/OSmb2Nw0FTVLBJiCHrXMAPaYjvt/sFPPGYW3pJvvW+4k4KAtVs8gUOKOA9aG+W v6Cg==
X-Gm-Message-State: APjAAAVTr4juXidwg/owOsQAsWsdagaeJgqBN+C5VwoiEmlO+cdsvENP nMXA4lsY2WMbCyG6fwu/FS19fHteXOYvsWtOXWQ=
X-Google-Smtp-Source: APXvYqx+R5Kb31OdBQ8ZYIs0j0zFwcsUn4sKHGv2RdEewJjt6aXfCFmVvgAO6CepV9ScPWzLXGdeFqCmaS81eZoXrBY=
X-Received: by 2002:a2e:98d7:: with SMTP id s23mr1833862ljj.179.1565099815205; Tue, 06 Aug 2019 06:56:55 -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>
In-Reply-To: <cb745eda-cbc7-b35a-d3fe-6cdecf3cfd05@cs.tcd.ie>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 6 Aug 2019 16:57:19 +0300
Message-ID: <CAMr0u6kWweGAaF3RoLNXkt3Np6xyfB_HxT6P1LLGFPqmVETqvg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Leo Perrin <leo.perrin@inria.fr>, cfrg <cfrg@irtf.org>, Dmitry Belyavsky <beldmit@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008602f8058f733269"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/8dCGIvv-46VM4LYoaA_R9Nhhf9E>
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 13:57:07 -0000

Dear Stephen,

>> So that sounds like an erratum may be worthwhile for each of 8624 and
7901? I guess the code points defined for DNSSEC are really for the old
algorithms and ought not point to the RFCs for the new ones?
>> And that hasn't really got anything to do with the meat of Leo's
findings - it's just that his work flagged up the erroneous references.
Personally, I agree that it would be good to do the updates here. But, as
for DNSSEC, I hope that the authors of RFC 5933 (or, maybe, Dmitry
Belyavsky) can comment better.



вт, 6 авг. 2019 г. в 16:33, Stephen Farrell <stephen.farrell@cs.tcd.ie>;:

>
> Hiya,
>
> On 06/08/2019 14:14, Stanislav V. Smyshlyaev wrote:
> > Stephen, GOST R 34.11-94 is built using a completely different
> > construction, so (Leo will correct me, if I am mistaken) the discovered
> > properties are not related to GOST R 34.11-94. I’d also like to clarify
> > that this GOST R 34.11-94 is an old hash function, which has been
> > deprecated for about 7 years in Russia.
>
> So that sounds like an erratum may be worthwhile
> for each of 8624 and 7901? I guess the code points
> defined for DNSSEC are really for the old algorithms
> and ought not point to the RFCs for the new ones?
> Those'd be valid errata I reckon, as it was a bit
> of a mistake (though entirely understandable) to
> refer to the new RFCs when the code points are for
> the old algorithms. Those errata would just say
> that the normative references to the new RFC were
> wrong and should've been to the old RFC. And that
> hasn't really got anything to do with the meat of
> Leo's findings - it's just that his work flagged
> up the erroneous references.
>
> As to whether to deprecate the algorithms due to
> Leo's findings, I agree that the existence of
> deployments that'd be affected needs to be taken
> into account in terms of the timing of when that
> might reasonably be done. And the fact that the
> algorithms in question are national standards is
> also a relevant point, though of course deprecating
> the RFCs has no formal effect on such national
> standards.
>
> Personally though, I think discovery of undeclared
> and unexplained structure such as this in a crypto
> algorithm ought be taken as a negative, even if there
> is no known attack at present, so I'd be for moving
> to deprecate when that is practical, in this case,
> as I would in any other similar case.
>
> Cheers,
> S.
>