[Cryptography] Informed opinion on China's SM3 hash ?
Jon Callas
jon at callas.org
Mon Dec 9 19:28:51 EST 2024
> On Dec 9, 2024, at 09:29, Salz, Rich via cryptography <cryptography at metzdowd.com> wrote:
>
> Does anyone have an informed (cryptographically-oriented, not politically) opinion about the SM3 hash algorithm?
> I ask because there is a pull request to add a hybrid MLKEM/25519 with SM3 instead of SHA3 as the digest. This is *adding* a key exchange mechanism and it will of course require both sides to want it. I am also asking because unlike SHA[123], MD[45], and the Gost digests, I haven’t seen much analysis of SM3. That could be my mistake, please let me know if so. I’ll send the PR URL to anyone who asks, if only to because I am most interested in SM3 the algorithm, not this particular use of it.
> Thanks. Replies to me will be summarized for the list.
I think it's basically okay.
The core function is really cryptographically resistant and has enough safety margin that I'd be wowed to see any problems. I don't like that it's got Merkle-Damgard (M-D) chaining, but there's some safety stuff added in that seems fine so long as you treat it as delicately as you'd treat SHA-256. By that I mean that you use HMAC with it, as opposed to any one-pass MACs or keyed hashes. (On the other other hand, there are a bunch of M-D issues that are not precisely practical, either.) Overall, I think it's a better hash function than SHA-256 because it has features to address questions about the design of SHA-256. I don't think it's as good as SHA-3, or any of its cohort, and at the same time, I don't think it matters. In a MLKEM it's going to be just fine.
Stylistically, it's from a design family that takes the history of M-D hashes and fixes those problems while keeping M-D instead of some other chaining mode. I'd call it the most astute of M-D hash functions; also note that "astute" is not exactly faint praise, and it's not ringing endorsement. Before SHA-3, M-D construction was the devil we knew. They took all the knowledge of M-D flaws (and let us not forget that it was Wang who brought down M-D construction!) and reinforced the system.
The criticisms I would make of it are that they didn't pick another chaining mode, it's an internal design with an assumption of a 32-bit processor and 512 bits of state, and it doesn't include features that bring rigor to the fact that hash functions are the multitools of cryptography. The high-level response to my criticisms is "so what?" and that's a pretty good point. M-D is the devil we know, and a counter-argument is that other chaining (or alternatives like sponges) has unknown issues. An M-D hash with Wang-driven reinforcement might be better than other alternatives! The multitool issue is addressed with outer wrappers like HMAC. And while I think my strongest criticism that it's conceptually a reinforced SHA-256 and not a reinforced SHA-512 (which could have been faster and would have more internal state), I don't have an answer to "so what?" Especially since there are ARMv8 enhancements for it.
In one last practical, realpolitik comment is that if you *don't* put it in, they're probably going to do it on their own and then the issue will come back when it's been deployed in so many places that people are just going to have to do it anyway. Thus, better to be part of the discussion than not.
So bottom like is that I toss it in with some competent other national algorithms like the block ciphers Camellia and SEED -- I'd rather not see them in the generic wild, and yet again, so what? I wouldn't say not to put money in a Korean bank because you have to use SEED. I wouldn't decline to work on a project with Japan because of Camellia. I wouldn't decline to work on something with China because they're insisting on SM4, yet at the same time, I'd want them to use SHA3 when working with me.
Jon
More information about the cryptography
mailing list