6.2 Merge window, part 1 [LWN.net]

6.2 Merge window, part 1

Posted Dec 15, 2022 19:19 UTC (Thu) by wsy (subscriber, #121706)
Parent article: 6.2 Merge window, part 1

SM2/SM3/SM4 cipher suites are highly likely backdoored. People with choices should never use them.

to post comments

6.2 Merge window, part 1

Posted Dec 15, 2022 23:53 UTC (Thu) by willy (subscriber, #9762) [Link] (6 responses)

I see no evidence that SM4 is weaker than AES. "it's from China" plays well on Fox News, but I like to think we have a higher standard of proof than that.

It's been a published algorithm since 2012. The best known attack is based on a 22-round version instead of the specified 32. Arguably, Rijndael is closer to being broken than SM4.

6.2 Merge window, part 1

Posted Dec 16, 2022 4:37 UTC (Fri) by wsy (subscriber, #121706) [Link] (5 responses)

I say this because as a Chinese I know how our gov works. They are control freaks.

The PKI standards built upon these cipher suites are called 双证书体系 or Dual-Certificate System. A user has to use saparate key pairs for encryption and signature. The encryption cert private key is issued by the key authority. The signature cert private key is generated by yourself and signed by the CA like a normal certificate.

So the gov can easily decrypt your communication while you have no plausible deniability. This is crazy. I doubt any sane person will trust those ciphers seeing this dual-cert system.

6.2 Merge window, part 1

Posted Dec 16, 2022 6:33 UTC (Fri) by uudiin (guest, #131856) [Link]

Dual-certificate design, or TLCP can sniff traffic content, but this can only be done on the premise of having a key, which does not mean that the SM2/3/4 algorithm itself is flawed, and there is currently no evidence that the algorithm itself it is not safe. of course, a dual-certificate system like TLCP will never be introduced into community software.

6.2 Merge window, part 1

Posted Dec 18, 2022 2:10 UTC (Sun) by anselm (subscriber, #2796) [Link] (2 responses)

So the gov can easily decrypt your communication while you have no plausible deniability. This is crazy. I doubt any sane person will trust those ciphers seeing this dual-cert system.

Yes, but that approach would work with any asymmetric cryptosystem (such as RSA). It doesn't indicate a weakness in the actual ciphers used in China. On the contrary, if the ciphers themselves were in fact backdoored, the Chinese government wouldn't even need to go through this elaborate “dual-certificate” song-and-dance routine in the first place.

6.2 Merge window, part 1

Posted Dec 19, 2022 11:48 UTC (Mon) by k3ninho (subscriber, #50375) [Link] (1 responses)

I have no way to assess the likelihood of the following, but there is an avenue where both flaws exist and the song-and-dance over certificates and public keys is a distraction from an exploitable flaw in the algorithm used.

K3n.

6.2 Merge window, part 1

Posted Dec 23, 2022 7:25 UTC (Fri) by anton (subscriber, #25547) [Link]

That is certainly a possibility. The British planted stories of spies to cover up the existence of Ultra (their successful cryptanalysis).

OTOH, the PRC government may just want their own cypher for fear of an NSA backdoor in cyphers coming from elsewhere.

6.2 Merge window, part 1

Posted Dec 22, 2022 18:05 UTC (Thu) by flussence (guest, #85566) [Link]

That sounds familiar. I don't remember where I saw it (LibreSSL dev blog?) but there was a version of AES that took four keys and did... *something* with them.

Don't overestimate people's sanity. After all, OpenSSL is still in use a decade later for some reason.

6.2 Merge window, part 1

Posted Dec 16, 2022 0:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

It's highly unlikely. If China knows a way to backdoor a cipher like SM4, then it's likely that AES is also vulnerable.

6.2 Merge window, part 1

Posted Dec 18, 2022 4:04 UTC (Sun) by Paf (subscriber, #91811) [Link] (3 responses)

There is an enormous difference between backdoor ing a particular cipher design when you’re designing it and cracking a related one. Choice of constants, etc, etc.

6.2 Merge window, part 1

Posted Dec 18, 2022 6:48 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

There are no constants in SM4 that are not derived from first principles. Just like AES, SM4 uses S-boxes for the round function. They are calculated using different polynomials, but otherwise they are very similar.

So it's extremely unlikely that SM4 is backdoored. And if it is, then AES is also pretty much guaranteed to be just as vulnerable.

It doesn't mean that everyone should switch to SM4, it's simply not a good modern cipher from a purely practical standpoint.

6.2 Merge window, part 1

Posted Dec 20, 2022 1:24 UTC (Tue) by Paf (subscriber, #91811) [Link] (1 responses)

“ The eight S-boxes of DES were the subject of intense study for many years out of a concern that a backdoor (a vulnerability known only to its designers) might have been planted in the cipher. The S-box design criteria were eventually published (in Coppersmith 1994) after the public rediscovery of differential cryptanalysis, showing that they had been carefully tuned to increase resistance against this specific attack. Biham and Shamir found that even small modifications to an S-box could significantly weaken DES.[4]”
From Wikipedia. From your description, you know more of the details of S-box creation than I do, but this sure sounds like an S-box could be weak in a way that might not be apparent to others.

6.2 Merge window, part 1

Posted Dec 23, 2022 3:45 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

S-Boxes in DES were basically chosen experimentally, they are not a result of any "nothing up my sleeves" process.

In contrast, both AES and SM4 use algorithmically generated S-Boxes. The algorithms are very similar, so it's highly unlikely that only one of them is vulnerable.

6.2 Merge window, part 1

Posted Dec 16, 2022 9:02 UTC (Fri) by InfoHunter (guest, #162753) [Link]

Don't mix up the security of cryptography primitives and secure network protocols. A specific protocol being not secure doesn't mean the cryptography primitives it uses are also vulnerable. The SM algorithms you mentioned have already all been standardized by ISO during the last few years.