[PATCH] sm3: implement SM3 hash algorithm
Weikeng Chen
w.k at berkeley.edu
Sun Oct 15 10:47:02 CEST 2017
I think it is unlikely that SM3 contains a backdoor.
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.
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