Emailed to TCG:

Forwarded message from Trusted Computing Group on Wed May 29, 2024 at 1:58 PM:
Message Body:
Some views on topic I've written:
- https://social.kernel.org/notice/AiNuw35YY9uOSrhiK0
- https://github.com/wolfSSL/wolfTPM/issues/356
Linux kernel patch set ongoing which made me realize that p256k1 is lacking from your registry:
- https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
This really should exist despite not being the most secure ECC given the compatibility to a number o
f open source projects and platforms (not just ETH and BTC). Please read also the above links, the w
rite ups are short and to the point. This would add by factors the importance of TPM2 ecosystem spre
ading to new applications.

--
This e-mail was sent from a contact form on Trusted Computing Group (https://trustedcomputinggroup.o
rg)

On possibility of adding TPM_ECC_SECP_P256_K1 curve to https://trustedcomputinggroup.org/wp-content/uploads/TCG-Algorithm-Registry-Revision-1.34_pub-1.pdf

Unless I overlooked something, which is entirely possible, Linux does not know how to sign even NIST-ECDSA (p256r1). That would make tpm2_key_ecdsa the first module that can do ECDSA signatures at all.

I think after TPM2 RSA/ECDSA work lands to mainline, I'll make software implementation of p256k1 ECDSA verification, and some time later, signing. That way at least TPM2 keys can root a key hierarchy for p256k1 keys to the Linux keyring, despite being just software implementation.

Stefan Berger has done during last 2-3 years a decent ecc_* API so should not be even a huge stretch.

So tpm2_key_ecdsa (if I did not overlook anything, cannot be 100% sure) might even enable ECDSA signing overall for Linux kernel for the first time.

#linux #kernel #keys #keyring

https://curl.se/libcurl/

Connecting to #Ethereum Name Service and similar crazy crypto distributed hellholes is dead easy with C: #libcurl. Also much more transparent than those crazy #Web3-frameworks :-) I don't know what they do in the machinery, so thus do not like them.

Dropped this question also to #wolfSSL: https://github.com/wolfSSL/wolfTPM/issues/356

#Microsoft has invested considerable amount of money on #Ethereum but still nobody has put forward p256k1 to the TCG Algorithm Registry. IMHO, would be somewhat dead obvious thing to do...

https://trustedcomputinggroup.org/resource/tcg-algorithm-registry/

#TPM #blockchain

I wonder if TCG is ever going to add p256k1 to their algorithm repository...

Asymmetric #TPM2 #keys v7:

https://lore.kernel.org/linux-crypto/20240528210823.28798-1-jarkko@kernel.org/T/#mb07f85a8c3f4af388cbc08438e71ac8aea447d85

This is the first version with fully working #ECDSA signing and signature verification with the public key.

Implementation notes:

1. Accepts only sha256 at this point. Can be easily extended later. It is best overall choice for the first version.
2. Does not accept any authentication policy yet. Can be extended later by adding a new parameter to match_table_t param_keys in security/keys/keyctl_pkey.c. E.g. "policy=%s".

I’m pretty happy with this, given that I did it fully during 1.5 week period on my free time and unpaid ;-)

#Linux #kernel #TPM

@GossiTheDog I'd generally prefer either Firefox or Chrome, or unbranded versions of them (like Debian's Iceweasel), even if there is zero controversies because obviously it is nearest the upstream where e.g. security fixes land first.

Linux 6.10-rc1 got released yesterday. With brand new `mseal()` system call.

So my automation kicked in, posted pull request, I merged, page with system calls table got rebuilt:

https://gpages.juszkiewicz.com.pl/syscalls-table/syscalls.html

@tshepang Ultimately I cannot say anything definitive as it is up to arch subsystem tree maintainers, but I would be less surprised to win in lottery, than see an arch subsystem tree that would require two cross-compilation toolchains to make a build. From that I can pretty much deduce the original claim that feature parity is mandatory for linux-rust to have any long-standing significance in linux kernel.

v6 of #TPM2 #asymmetric #keys patch set: https://lkml.org/lkml/2024/5/28/150

The new version includes also sub-type for ECDSA signing and verification.

#linux #kernel

@tshepang Not something that pro-actively waiting for but before that happens Rust is by.practical means blocked from defconfig's. It is then up to those who work on these compilers to find a way to make it happen (such as ISO standard).

@tshepang Rust is already enabled in Linux but it has insignificant chance to reach any arch's defconfig before feature parity with gccrs. What is an "ok thing"?

@tshepang not really understanding the context where this would happen, I'm not waiting for anything at all :-)

@tshepang Because Linux supports GCC 🤷 And for anything compiled by default, i.e. in any defconfig, requiring two toolchains for a build is obnoxious and neither very portable. E.g. for specific cross-compilation target you might have only one toolchain.

@raggi Yeah, agreed :-)

@raggi Is there some other fronend for LLVM than rustc? Not sure I got hold of this argument.

@raggi Yeah, please understand that I would love to see some day rust in some arch's defconfig :-) So not claiming that I know things better than e.g. respective language communities but instead am just documenting here my own concerns.

I'm also happy to get things totally wrong :-) I never "defend" any of my opinions at the time...