[PATCH] sm3: implement SM3 hash algorithm
r030t1 at gmail.com
Tue Oct 17 22:36:27 CEST 2017
On Sun, Oct 15, 2017 at 6:59 PM, Weikeng Chen <w.k at berkeley.edu> wrote:
>  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
Thank you for your understanding.
>  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 am not sure what this has to do with anything I said. Is the entire
population of China expert cryptographers? No? Then what I said holds,
and isn't an insult.
I feel like I should point out for the rest of the list that finding
insults where there are none is a propaganda tactic that the Chinese
state media employs liberally.
> 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.
I think you misunderstand the desires of a nation state. The
government mandates the use of these algorithms likely because they
are broken in a hard to recover way. This means that the government
can "secure" its internal communication, but still leave it accessible
to eavesdropping by itself.
I am not sure why you commented on the security of those other
algorithms. I never implied SM3 had any relation to them or their
If the above sounds too paranoid for you, then I am not sure what to say.
>  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.
You also need to consider the other evidence presented. It seems like
you have, and you understand why the things I mentioned (special
constants, unjustified changes) reflect poorly on the algorithm.
Those points are important enough but also understandable enough that
any other discussion on the matter is pointless.
See also my previous post, where I note that those other algorithms
are included for historical reasons. This algorithm has no historical
reason for inclusion.
>  Unlike asymmetric encryption, the evaluation of symmetric
> encryption is really hard.
In this case, it isn't. The authors of SM3 made huge mistakes that
discredit the algorithm in its entirety.
> 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:
>> 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.
>>> gcrypt cannot have all new functions -- otherwise, why not balloon
>>> hashing and scrypt (the latter is used in many kinds of
>>> 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
>>>> 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. 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 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, a fork of OpenSSL which
>>>> contains various cryptographic standards developed by the Chinese
>>>> government that were, presumably, not deemed fit for inclusion in
>>>> 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.
>>>> : https://eprint.iacr.org/2012/274.pdf, also attached.
>>>> : https://tinycrypt.wordpress.com/2017/02/22/asmcodes-sm3/
>>>> : http://gmssl.org/
>>>> Gcrypt-devel mailing list
>>>> Gcrypt-devel at gnupg.org
>>> Weikeng Chen @ 795 Soda Hall
> Weikeng Chen @ 795 Soda Hall
More information about the Gcrypt-devel