[PATCH] sm3: implement SM3 hash algorithm

R0b0t1 r030t1 at gmail.com
Tue Oct 17 20:48:20 CEST 2017

On Sunday, October 15, 2017, Jia Zhang <qianyue.zj at alibaba-inc.com> wrote:
> Everyone has different expection with gcript, and personally I respect
the established fact:
> - TCG approved
> - Not broke
> - Known weak algorithms still exist in gcrypt
> gcrypt is not arrogant. It helps to extend the use of cryptography usage.
> I think it is time to end up talking about all non-engineering
discussion. Until now there is no people talking about the code itself.

If the algorithm is so weak or suspicious as to preclude inclusion in
gcrypt then there is no point in discussing the details of your patch.

However, to my dismay, the priorities of gcrypt lie elsewhere and it seems
as is your patch will be accepted.

Most of the weak algorithms are included for historical reasons. This one
need not be included.

Besides SM3's technical deficiencies, it should be obvious it fails a test
of notability. Outside of the Chinese speaking internet no one seems to
care about it, save for situations like the one happening now where people
are trying to argue to others who have no reason to care that SM3 is

This is not xenophobia. The algorithm is suspicious and looks like it is


> 于 2017/10/16 上午8:01, Weikeng Chen 写道:
>> [1] Understood your concern that SM3 does not release the reason for
>> picking constants. This is somehow not solvable.
>> I think this is a sufficient reason not to include it in the gpupg.
>> Because including it would be regarded as an endorsement from open
>> source community. If one day something is wrong, it would be
>> problematic.
>> [2] off-topic issues. Please believe that people in China visiting
>> Google, Facebook, and Youtube are already experts in censorship
>> circumvention (but it is not that easy) -- we are not that stupid
>> after all and not that controlled by the government.
>> I think you misunderstand the usage of SM1-4. It is only used for
>> government-relevant or critical circles (that would be another reason
>> that it is not needed to include today). It is impossible to be used
>> to alternate the HTTPS or anything in today's Internet. So, the
>> government using SM1-4 everywhere does not make it an advantage in
>> breaking our RSA/ECDSA/SHA2/SHA3 based Internet communication that the
>> major public is using (I think we should partly attribute this to the
>> development of gpupg).
>> The political concern now goes a little bit far.
>> [3] Independent of this, I think it is crucial that we have a general
>> rule to discuss to accept or not accept a cipher into gcrypt. Although
>> it is unlikely that in recent years, new standards to replace AES and
>> SHA3 are needed.
>> "Just because you personally can not imagine some weakness in SM3 does
>> not mean there are no weaknesses in SM3."
>> This is not a gold standard that we can use in the future.
>> Cryptography is based on problems that we believe hard today. If P=NP,
>> then theoretically, we have rightly zero cryptographic primitives that
>> can be long-term secure. Many reasons to dispute SM3 can also be used
>> to criticize SHA3, SHA2. No need to say MD2, MD4. There are a bunch of
>> papers on the reduced-round attack in many mainstream ciphers in
>> CRYPTO. But "attack-paper-less" cryptographic algorithms are also not
>> good because of few discussions.
>> [4] Unlike asymmetric encryption, the evaluation of symmetric
>> encryption is really hard.
>> Weikeng
>> On Sun, Oct 15, 2017 at 4:21 PM, R0b0t1 <r030t1 at gmail.com> wrote:
>>> On Sun, Oct 15, 2017 at 3:47 AM, Weikeng Chen <w.k at berkeley.edu> wrote:
>>>> I think it is unlikely that SM3 contains a backdoor.
>>> This is giving the authors of SM3 a dangerous amount of credit where
>>> it is not due. Their algorithm fails a very basic test:
>>> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number.
>>> At best, they don't know what they are doing and made changes
>>> randomly. At worst, they made changes to make the algorithm
>>> susceptible to an undisclosed attack and could find no justification
>>> to use as a lie.
>>> Just because you personally can not imagine some weakness in SM3 does
>>> not mean there are no weaknesses in SM3.
>>>> It is intended to be used in governments and mission-critical devices.
>>>> There is no reason to use something dangerous (then U.S. can break?).
>>>> And it is generally not that easy to add a backdoor in a symmetric
>>>> algorithm if we obtain randomness from a physical source.
>>> The problem with proving a negative in this context; that is, proving
>>> there are no back doors to the algorithm, is that it takes a huge
>>> amount of work. The "Limitations" section of the Wikipedia article
>>> above explains it well: the problem space is so large that any number
>>> of design constraints could have been engineered to provide a weakness
>>> that is only accessible to a party with special knowledge. In this
>>> sense a weakness can be made "safe" and turned into a back door.
>>> This is one of the major reasons that lack of cryptanalysis for an
>>> algorithm is suspicious: other researchers could consider it a waste
>>> of time to investigate a plausibly backdoored algorithm.
>>> Even if, however, other nation states were already aware of and could
>>> exploit the weakness, I expect that China would use a weak algorithm.
>>> China may not have the capabilities that other actors do, and may need
>>> to rely on algorithms that would be considered weak to other actors if
>>> China wants to monitor communication within its borders.
>>> As a good example, look at Russian certificate authorities and content
>>> hosts. Many of them use very weak cryptographic keys. I have seen many
>>> 512 bit RSA keys that are nowhere close to expiring. Seeing as the
>>> Russian intelligence services are apparently not capable of factoring
>>> extremely large primes, they "recommend" weak keys to their citizens
>>> (or for some other reason many businesses use weak keys). The intent
>>> behind this is to protect communication from civilian espionage but
>>> not from their own state or other states.
>>> Respectfully,
>>>       R0b0t1
>>>> gcrypt cannot have all new functions -- otherwise, why not balloon
>>>> hashing and scrypt (the latter is used in many kinds of
>>>> cryptocurrency)?
>>>> On Sat, Oct 14, 2017 at 1:16 PM, R0b0t1 <r030t1 at gmail.com> wrote:
>>>>> On Sat, Oct 14, 2017 at 12:05 PM, 张佳(乾越) <qianyue.zj at alibaba-inc.com>
>>>>>> Hi Werner,
>>>>>> This is the review request for SM3 hash algorithm. Plz see the commit
>>>>>> header and patch for more details.
>>>>>> SM3 hash algorithm is already accepted and supported by TPM 2.0 spec.
>>>>>> So it is necessary to implement this algorithm in a famous open
>>>>>> software for checking the digest value computed by TPM.
>>>>>> Plz refer to this PR (https://github.com/gpg/libgcrypt/pull/2) for
>>>>>> review.
>>>>>> Thanks,
>>>>>> Jia
>>>>> Jia,
>>>>> It is my understanding that SM3 was not accepted into any global TPM
>>>>> specification and is merely mandated for use within China.
>>>>> My research on SM3 has turned up only one detailed cryptanalysis of
>>>>> the function.[1] That cryptanalysis implies that the techniques used
>>>>> to "strengthen" SM3 do not accomplish what the creators claim, and may
>>>>> even weaken the hash function when compared to its inspiration, SHA-2.
>>>>> Less detailed analysis[3] of the claims presented by the creators
>>>>> reflect poorly on their work. For starters, none of the techniques
>>>>> meant to increase the security of SM3 are explained. Their utility is
>>>>> unknown, and a cursory glance shows that in at least one case a round
>>>>> operation is simplified. Perhaps more distressing is the selection of
>>>>> constants with no justification.
>>>>> It seems very likely that the algorithm has undisclosed backdoors.
>>>>> Also pertinent is the existence of GmSSL,[3] a fork of OpenSSL which
>>>>> contains various cryptographic standards developed by the Chinese
>>>>> government that were, presumably, not deemed fit for inclusion in
>>>>> OpenSSL.
>>>>> Inclusion of weak cryptography in gcrypt would be a disservice to
>>>>> those users which trust gcrypt with their life. I understand I am not
>>>>> the person to whom you addressed your message, nor am I a gcrypt
>>>>> developer, but I felt it necessary to reply to this conversation.
>>>>> Respectfully,
>>>>>       R0b0t1
>>>>> [1]: https://eprint.iacr.org/2012/274.pdf, also attached.
>>>>> [2]: https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/
>>>>> [3]: http://gmssl.org/
>>>>> _______________________________________________
>>>>> Gcrypt-devel mailing list
>>>>> Gcrypt-devel at gnupg.org
>>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>>>> --
>>>> Weikeng Chen @ 795 Soda Hall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20171017/688ecf77/attachment-0001.html>

More information about the Gcrypt-devel mailing list