[PATCH] sm3: implement SM3 hash algorithm

Weikeng Chen w.k at berkeley.edu
Mon Oct 16 02:01:50 CEST 2017


[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



-- 

Weikeng Chen @ 795 Soda Hall



More information about the Gcrypt-devel mailing list