[PATCH] sm3: implement SM3 hash algorithm

[R0b0t1]

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