This looks like an eminently reasonable simplification. Could I get a signed-off-by for DCO attestation: https://www.developercertificate.org/ I should probably actually give the project a contributin

The TPM wants to do the digest truncation itself, so this will fail if the curvebits converted to bytes aren't a recognized digest size. Of the currently listed curves in the TCG registry, this will h

[adding the list because we actually have one now] Got to confess, this isn't something I've tried directly (so I will test it out and see what the problem is). However, both the openSUSE and debian p

No as I explained in the other email, the openssl_tpm2_engine mostly keeps the TPM clear when it's not doing anything even if the key is present and referenced from an openssl point of view. Yes, it's

The openssl_tpm2_engine typically only uses 1 session for each command. We use the same session for hmac and decryption and we don't run audits. I think all of the commands we use only require at most

This sounds a bit serious. I've taken the liberty of cc'ing the linux- integrity group which is the mailing list where kernel based TPM issues get discussed. Error -5 is EIO which still points to a TP

Oh boy, this is a nasty one: it's TPM_RC_INTEGRITY. It means that the integrity check failed of the context we're trying to load into the TPM. I've never seen this in all my stress testing of the in-k

This isn't actually response code unknown, it's TSS_RC_MALFORMED_PUBLIC and it means the public structure doesn't match the name. I've seen this before as a bug in one of the ECC routines where there

[...] Actually, here I disagree: the faults in PKCS11 are why we have a problem and a boat load of not quite functional solutions: it has no key id API, so it can't take files, pkcs11: or any other UR

Hey don't beat me on the sore spot ... Actually, it doesn't ... that's the nice thing about the project: it's entirely key format agnostic. It just takes the engine name and the key file and hands it

The big problem is which token? There are enough TPM PKCS11 implementations to fill a small warehouse. The Thomas Habets one seems to be the best thought out: https://github.com/ThomasHabets/simple-tp

Well, you can't have the engine name hard coded ... that really needs to be some type of parameter, which is going to be 99% of the hassle making a proper patch ... Just on this particular part: I rec

Add general tests of the new command plus a specific test of the ability to create a key to a wrapped parent, clear the TPM (thus effectively creating a new tpm), re-wrapping the key and demonstrating

In order to use restricted keys as parents, they have to be loaded into the TPMs NV handle area, so introduce a new command to do that. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnershi

We've been obscuring a bug in tpm2_rm_tssdir() for a while in that we create a key file for the parent non volatile key but don't remove it again. We fixed it up in tpm2_rm_tssdir() by hard coding the

Right at the moment we create unrestricted signing and decryption keys. These keys are the most useful for cryptographic operations, but they cannot be used as parents for any other key. The addition

This is a tiny code change (missed one case of key file removal in patch 2) but a big increase of the amount of testing done (patch 4) Original cover letter: This patch series adds restricted keys, wh

Add general tests of the new command plus a specific test of the ability to create a key to a wrapped parent, clear the TPM (thus effectively creating a new tpm), re-wrapping the key and demonstrating

In order to use restricted keys as parents, they have to be loaded into the TPMs NV handle area, so introduce a new command to do that. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnershi

We've been obscuring a bug in tpm2_rm_tssdir() for a while in that we create a key file for the parent non volatile key but don't remove it again. We fixed it up in tpm2_rm_tssdir() by hard coding the