Jarkko Sakkinen
jarkko
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
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
0
0
0
Dropped this question also to #wolfSSL: https://github.com/wolfSSL/wolfTPM/issues/356
0
0
0
Jarkko Sakkinen
jarkko
#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
https://trustedcomputinggroup.org/resource/tcg-algorithm-registry/
#TPM #blockchain
1
0
0
Jarkko Sakkinen
jarkko
Edited 2 years ago
This is the first version with fully working #ECDSA signing and signature verification with the public key.
Implementation notes:
- Accepts only sha256 at this point. Can be easily extended later. It is best overall choice for the first version.
- Does not accept any authentication policy yet. Can be extended later by adding a new parameter to
match_table_t param_keysinsecurity/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 ;-)
1
0
1
Jarkko Sakkinen
repeated
repeated
Jarkko Sakkinen
jarkko
@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.
0
0
1
Jarkko Sakkinen
repeated
repeated
Marcin Juszkiewicz š
hrw@society.oftrolls.comLinux 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
0
2
2
@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.
1
0
0
Jarkko Sakkinen
jarkko
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
The new version includes also sub-type for ECDSA signing and verification.
#linux #kernel
0
0
1
@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).
2
0
0
@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...
I'm also happy to get things totally wrong :-) I never "defend" any of my opinions at the time...
0
0
0
@raggi In the end of the day I don't mind how 1:1 compatibility with the language spec is maintained as long as it works for rustc and GNU project. If it works for both with Github, then it is not my problem. I'm just consumer for these tools and part of neither community. Still for kernel, gccrs must have enough features to be drop-in replaceable with rustc, at least to compile kernel. In the long-term at least.
0
0
0