back
10 comments
A buffer overflow in the Chinese national SM2 ECC cipher, which presumably nobody has enabled in North America.
It looks like its inclusion is guarded by a compiler flag: https://github.com/openssl/openssl/blob/b93f6c2db94f736b497f...

If anyone needs to know if SM2 is enabled quickly on any system, `openssl list --public-key-methods` is guaranteed to include "sm2" in the output if it's compiled. Therefore, if this returns 1, you have SM2 compiled in:

    openssl list --public-key-methods | grep sm2 | wc -l
(There's probably better commands, but that'll get the job done. Compiled doesn't mean "enabled by TLS", of course.)

That said, assuming I'm reading the right docs, SM2 is interesting: https://crypto.stackexchange.com/a/67481/87778 https://en.wikipedia.org/wiki/SM9_(cryptography_standard)#Ch...

It prefixes the hash of the message with the public key, presumably to ensure exclusive ownership. https://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf

Additionally, SM2 signature verification requires no modular inversion.

This is neat stuff. I've never really bothered to look deeply at Chinese cryptography before.

Probably you meant "grep sm2"?
> which presumably nobody has enabled

If you mean compiled into libssl, openssl seems to include it by default, so I'd guess the majority of linux distros have it enabled. They'd have to go out of their way to configure it off, and distros typically defer to upstream wherever they can.

But other nations wanting to hack into China might care.
No way, they have the great firewall! /s
Debian in its infinite wisdom has it enabled.
I just ran openssl list --public-key-methods on a Debian 10 box and you’re indeed right. I wonder why they chose to include it…?
I'm guessing this is common API design in the world of C libraries? Coming from Swift / other high-level languages, it seems awfully error-prone to have to call an API multiple times, sometimes with null arguments, sometimes with pointers to buffers that hopefully are the right size, just to process some data. Programmer errors / misinterpretation of the documentation leading to programmer errors seems inevitable.
Yes this is common design in cases where a library is used from memory-managed language but does not want to do own allocation. Very useful in case like embedded where some screwy behavior are needed for allocating correct.