linux-kernel - Re: [PATCH v3 0/2] use SM3 instead of SM3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cc3cf5e6-8946-65fc-014f-6641619fb2dc@linux.alibaba.com>
Date:   Mon, 29 Nov 2021 21:01:24 +0800
From:   Tianjia Zhang <tianjia.zhang@...ux.alibaba.com>
To:     Ard Biesheuvel <ardb@...nel.org>,
        James Bottomley <jejb@...ux.ibm.com>,
        Jarkko Sakkinen <jarkko@...nel.org>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, Jonathan Corbet <corbet@....net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Peter Huewe <peterhuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        David Howells <dhowells@...hat.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Jerry Snitselaar <jsnitsel@...hat.com>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        keyrings@...r.kernel.org,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3 0/2] use SM3 instead of SM3_256



On 10/27/21 12:08 AM, Ard Biesheuvel wrote:
> On Tue, 26 Oct 2021 at 09:56, Tianjia Zhang
> <tianjia.zhang@...ux.alibaba.com> wrote:
>>
>> According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html,
>> SM3 always produces a 256-bit hash value and there are no plans for
>> other length development, so there is no ambiguity in the name of sm3.
>>
> 
> What is the point of these changes? Having '256' in the identifiers is
> merely redundant and not factually incorrect, so why can't we just
> leave these as they are?
> 

Sorry for the late reply. This is just to fix the ambiguity that may be 
caused by the macro name. It seems that there is no need to modify it. 
Please ignore this patch.

Kind regards,
Tianjia