[PATCH] sm3: implement SM3 hash algorithm

[R0b0t1]

On Tue, Oct 17, 2017 at 8:09 PM, Jia Zhang <qianyue.zj at alibaba-inc.com> wrote:
>
>
> 于 2017/10/18 上午2:48, R0b0t1 写道:
>> 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 notable.
>>
>> This is not xenophobia. The algorithm is suspicious and looks like
>> it is backdoored.
>
> It is good to have a connection with TCG committee member and ask for
> why. I believe they made a careful assessment of accepting SM3 into
> TPM 2.0 spec and have the answers you are concerning about.
>
> Jia
>

Standards bodies will often do what governments request regardless of
reason. In this case, having compliant products sold in China was
enough of a carrot that I expect no true assessment took place. If SM3
was not included, the Chinese government would have simply created
their own standard and fragmented the market.

Respectfully,
     R0b0t1

>>
>> Respectfully, R0b0t1
>>
>>>
>>> 于 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>
>> wrote:
>>>>>>>>
>>>>>>>> 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
>> source
>>>>>>>> software for checking the digest value computed by
>>>>>>>> TPM.
>>>>>>>>
>>>>>>>> Plz refer to this PR
>>>>>>>> (https://github.com/gpg/libgcrypt/pull/2) for
>> code
>>>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>