[PATCH] sm3: implement SM3 hash algorithm

Jia Zhang qianyue.zj at alibaba-inc.com
Mon Oct 16 03:07:50 CEST 2017


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.

Jia

于 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
>
>
>



More information about the Gcrypt-devel mailing list