Hello,
Post by Jia ZhangPost by Bruno HaibleIndeed, we don't have many crypto experts on the gnulib mailing
lists. Therefore, I too would like the crypto experts on the
libgcrypt or openssl mailing lists to evaluate the SM3 algorithm
and your code first, before we can accept it in gnulib.
libgcrypt has merged SM3 hash function. See
https://dev.gnupg.org/rC4423bf3cc4432b9bfe801ff74cb05e6f0dd3eccd
I see SM3 has been added to gnulib and libgcrypt,
but I would suggest we wait for further evaluation before adding it to
coreutils.
libgcrypt specifically say: "Thorough understanding of
applied cryptography is required to use Libgcrypt."
and Werner Koch explicitly acknowledged that they are willing to include
known weak algorithms in libgcrypt because non-experts should never use
it directly:
https://lists.gnupg.org/pipermail/gcrypt-devel/2017-October/004287.html
I'm assuming the same applies to gnulib - but not to coreutils.
I won't claim to have any understanding of cryptography or hashing,
but a cursory look at the code raises three red flags:
First,
It is *very* similar to sha256.
Not just the function structure, but almost line-for-line identical.
It could almost be said that SM3 is just a modified sha256 with slightly
different primitives.
(try "diff -u lib/sm3.c lib/sha256.c" to see what I mean).
sha256 was published in 2001, and while it has not yet been compromised,
I would naively think it is not wise to offer a new hashing algorithm in
2017 that's based on sha256.
I think it is already generally recommended to move away from sha-256
to at least sha-512 (or sha-3).
Second,
All SHA-2 hash functions use initialization values that
are based on the cube roots of the first 62 primes.
In lib/sha256.c it is the "sha256_round_constants" variable.
In lib/sm3.c these initialization values are the same 32bit values,
rotated:
/* SM3 round constants */
#define T(j) sm3_round_constants[j]
static const uint32_t sm3_round_constants[64] = {
0x79cc4519UL, 0xf3988a32UL, 0xe7311465UL, 0xce6228cbUL,
0x9cc45197UL, 0x3988a32fUL, 0x7311465eUL, 0xe6228cbcUL,
0xcc451979UL, 0x988a32f3UL, 0x311465e7UL, 0x6228cbceUL,
0xc451979cUL, 0x88a32f39UL, 0x11465e73UL, 0x228cbce6UL,
0x9d8a7a87UL, 0x3b14f50fUL, 0x7629ea1eUL, 0xec53d43cUL,
0xd8a7a879UL, 0xb14f50f3UL, 0x629ea1e7UL, 0xc53d43ceUL,
0x8a7a879dUL, 0x14f50f3bUL, 0x29ea1e76UL, 0x53d43cecUL,
0xa7a879d8UL, 0x4f50f3b1UL, 0x9ea1e762UL, 0x3d43cec5UL,
0x7a879d8aUL, 0xf50f3b14UL, 0xea1e7629UL, 0xd43cec53UL,
0xa879d8a7UL, 0x50f3b14fUL, 0xa1e7629eUL, 0x43cec53dUL,
0x879d8a7aUL, 0x0f3b14f5UL, 0x1e7629eaUL, 0x3cec53d4UL,
0x79d8a7a8UL, 0xf3b14f50UL, 0xe7629ea1UL, 0xcec53d43UL,
0x9d8a7a87UL, 0x3b14f50fUL, 0x7629ea1eUL, 0xec53d43cUL,
0xd8a7a879UL, 0xb14f50f3UL, 0x629ea1e7UL, 0xc53d43ceUL,
0x8a7a879dUL, 0x14f50f3bUL, 0x29ea1e76UL, 0x53d43cecUL,
0xa7a879d8UL, 0x4f50f3b1UL, 0x9ea1e762UL, 0x3d43cec5UL,
Third,
The 64 rounds ("Compression function") in sha256 seem to
rotate the internal state variables equally (a..h)
in the R macro definition [1] and usage [2].
[1] https://opengrok.housegordon.com/source/xref/gnulib/lib/sha256.c#484
[2] https://opengrok.housegordon.com/source/xref/gnulib/lib/sha256.c#504
In sm3, it seems from a cursory look that the first 128 bits
and the last 128 bits of internal states are kept mostly separated
(variable a..d and e..h) based on the R macro [3] and usage [4].
[3] https://opengrok.housegordon.com/source/xref/gnulib/lib/sm3.c#377
[4] https://opengrok.housegordon.com/source/xref/gnulib/lib/sm3.c#413
Again, I'm not a cryptography expert, and perhaps this is secure.
But it does look a bit suspicious.
---
It's one thing to add it to a library, where it can not be accidentally
used by non-expert users, but it's a different thing to provide an
executable that will be shipped by default on all future GNU/Linux
machine.
I would humbly suggest we wait until other crypto experts evaluate
'sm3', and decide to offer it in their programs (preferably openssl /
libressl) as a general-purpose program.
regards,
- assaf