Enablement of other TPM 2 algorithms: Assess which Distros' OpenSSL supports 'what'

[stefanberger]

Assess the support of encryption and hash algorithms that libtpms could still enable and in which distros they are supported.

[stefanberger]

SHA3: grep -r SHA3_ /usr/include/openssl/ or openssl dgst --list | grep sha3
SM2: grep -r SM2 /usr/include/openssl/
SM3: grep -r SM3 /usr/include/openssl/ or openssl dgst --list | grep sm3
SM4: grep -r SM4 /usr/include/openssl/ or openssl enc -ciphers | grep sm4
Camellia: readelf -s /usr/lib64/libcrypto.so| grep Camellia or openssl enc -ciphers | grep camellia

	SHA3 hash family	SM3 (hash)	SM4 (sym. crypto)	Camellia (crypto)
RHEL 8	yes	yes	no	yes
CentOS 9	yes	yes	no	yes
Ubuntu 18.04	no	no	yes	yes
Ubuntu 20.04	yes	yes	yes	yes
Fedora 34	yes	yes	no	yes
Alt Linux (Sisyphus)	yes	yes	yes	yes
SuSE Leap (15.3)	yes	yes	yes	yes
SuSE Tumbleweed (20210806)	yes	yes	yes	yes
Alpine (3.14.1)	yes	yes	no	yes
Debian (10=buster)	yes	yes	yes	yes
Cygwin	yes	yes	no	yes
OpenBSD 6.8	no	yes	yes	yes
DflyBSD	no	yes	yes	yes
FreeBSD	yes	yes	yes	yes
OS X	no	no	no	yes
Summary	No: SHA3 context structure not accessible	No: APIs for SM3 (EVP) do not fit with 'level' of SHA APIs; SM3 context not accessible	breaks one TpmProfile.h accross distros	yes (enabled in v0.9)

(1): SHA3 family and/or SM3 hash would have to be enabled in firmwares also to appropriately measure, extend into PCR banks of those hashes, and log (EDK2, SLOF, SeaBIOS, etc.) IF the PCR bank were to be enabled; IMA also needs to supported them

[DemiMarie]

OpenSSL is not a good fit for libtpms. Nettle seems like a much better choice.

[stefanberger]

OpenSSL is not a good fit for libtpms. Nettle seems like a much better choice.

Why is/was Nettle better than OpenSSL's crypto library? Is it available across all the Linux & BSD distros like OpenSSL or LibreSSL?

The decision whether to use OpenSSL was made several years ago also based on the fact that the TPM 2 reference code was based on OpenSSL (partially at least) and for better or worse it's OpenSSL crypto now -- it's also a bandwidth issue on my side. A reason back then was certainly that OpenSSL's crypto library had the API that the TPM 2 needed and experience with it. How the API evolved over time, what is being deprecated over time, is not something that was foreseeable.

[DemiMarie]

OpenSSL is not a good fit for libtpms. Nettle seems like a much better choice.

Why is/was Nettle better than OpenSSL's crypto library?

OpenSSL is intended to be a high-level crypto library for use by applications. Nettle is intended to be a low-level crypto library that directly exposes the underlying primitives. From what I have observed, libtpms and the TPM 2 reference code need the latter, not the former.

To the best of my knowledge, Nettle also provides a much more stable API than OpenSSL. Despite suppressing deprecation warnings, I cannot compile Microsoft’s TPM reference implementation because of OpenSSL API changes. I do not believe Nettle has had anywhere near as many API changes, which is likely because it is a lower-level library.

Is it available across all the Linux & BSD distros like OpenSSL or LibreSSL?

I believe so. It also follows a policy of zero memory allocations for its symmetric cryptography. The asymmetric cryptography is not zero-allocations, but I suspect patches to make it so would be accepted. Nettle is also on the list of approved cryptographic libraries in RHEL.

The decision whether to use OpenSSL was made several years ago also based on the fact that the TPM 2 reference code was based on OpenSSL (partially at least) and for better or worse it's OpenSSL crypto now -- it's also a bandwidth issue on my side. A reason back then was certainly that OpenSSL's crypto library had the API that the TPM 2 needed and experience with it. How the API evolved over time, what is being deprecated over time, is not something that was foreseeable.

That is absolutely understandable.

[gaetan-sbt]

Would you consider implementing other EC curves, like 25519? They've been accepted in the TCG standard.

[stefanberger]

Would you consider implementing other EC curves, like 25519? They've been accepted in the TCG standard.

Considering, 'yes'. Will have to look how it can be supported across all distros.

[gaetan-sbt]

Ok. How can I help with that? Easiest way I know to check for support is to check the return value for
openssl genpkey -algorithm x25519.

From what I could check on my machines:

• Debian 11: yes
• OS X: yes

[stefanberger]

Ok. How can I help with that?

I am not sure yet how this curve needs to be implemented. But any step towards an implementation may be helpful... including test cases.

[wiktor-k]

Would you consider implementing other EC curves, like 25519? They've been accepted in the TCG standard.

Sorry to hijack this thread but would you mind linking to specs about that or some other public info? The only thing I found were codepoints in TPM-2.0-1.83-Part-2-Structures-1 but no further info on how to use it for, say, signing. (I'm interested in that curve too).

[gaetan-sbt]

@wiktor-k
The information I gathered is in this blogpost: https://cryptographycaffe.sandboxaq.com/posts/protecting-signal-desktop-keys/#fn:8. The footnotes 8 and 9 contain information of interest.

AFAIK, there is no implementation (hw or sw) of these curves with a TPM interface.

[stefanberger]

Would you consider implementing other EC curves, like 25519? They've been accepted in the TCG standard.

Sorry to hijack this thread but would you mind linking to specs about that or some other public info? The only thing I found were codepoints in TPM-2.0-1.83-Part-2-Structures-1 but no further info on how to use it for, say, signing. (I'm interested in that curve too).

Here's a TCG spec that at least mentions Curve 25519: https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf