The way I understand the ECDSA standard, it is supposed to truncate the provided hash - which is why it is possible to have ECDSA-over-P256-SHA384.
One possibility would be for you to truncate the SHA2 output yourself, IMHO.
On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" <openssl-users-bounces@xxxxxxxxxxx on behalf of andreas.fuchs@xxxxxxxxxxxxxxxxx> wrote:
The problem is as follows:
The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM.
If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes.
So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation.
Kind of stupid, I know, but thats how it goes.
For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent.
Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support).
Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512.
That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl.
I just don't know enough about OpenSSL as to where to start with this.
Anyone have any hints please ?
________________________________________
From: William Roberts [bill.c.roberts@xxxxxxxxx]
Sent: Friday, November 30, 2018 15:55
To: openssl-users@xxxxxxxxxxx
Cc: Fuchs, Andreas
Subject: Re: Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
<andreas.fuchs@xxxxxxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
> The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.
What about when keys aren't restricted to one specific signing scheme
and support raw encrypt/decrypt?
You could just synthesize it by building up the signature structure on
the client side
and using the raw primitives to encrypt the signing structure directly.
>
> Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31
>
> Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
> Thus: Is the following approach correct ?
>
> So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
> - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
> - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
> - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
> - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
> - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?
>
> Thanks a lot for any advice,
> Andreas
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
