salt length check failed

[amin1best]

Hi, According to https://github.com/OpenVPN/openvpn/issues/505, I can't use OpenVPN with tpm2-openssl and I get the following error:

OpenSSL: error:02000088:rsa routines::salt length check failed:expected: 32 retrieved: 222

@gotthardp , @levitte and and others, can you help me?

[levitte]

This happens in RSA_verify_PKCS1_PSS_mgf1(), and is likely to happen when the wrong MGF1 hash function is used for the signature that's being verified, if I'm not mistaken.

It would be good if you could show a bit more context around that error, like what exactly did you call, and with what parameters?

[selvanair]

This happens in RSA_verify_PKCS1_PSS_mgf1(), and is likely to happen when the wrong MGF1 hash function is used for the signature that's being verified, if I'm not mistaken.

Based on OpenVPN logs posted by OP to https://github.com/OpenVPN/openvpn/issues/505 this appears to be caused by TPM at the client side using max salt length for RSAPSS (222 in this particular case) while OpenSSL at server side expects the salt length to match that of digest (32 here) for TLS 1.3.

See also #75 which looks related.

[amin1best]

@levitte , thanks for the follow up. My environment:

Debian 12
OpenVPN 2.6.3
OpenSSL 3.0.11
TPM9660-TT

I followed the commands below:

tpm2_createprimary -c primary_sh.ctx
tpm2_evictcontrol -c primary_sh.ctx 0x81000001

openssl genpkey -provider tpm2 -algorithm RSA -pkeyopt bits:2048 -pkeyopt parent:0x81000001 -out rsakey.pem

openssl pkey -provider tpm2 -provider default -in rsakey.pem -pubout -out rsakey.pub.pem

openssl req -new -provider tpm2 -provider default -key rsakey.pem -subj "/CN=TPM/O=TPM" -out rsakey.csr.pem

Send CSR to CA and get certificate.

openvpn --config ./client.conf --ca ./ca.crt --cert ./cer.pem --key ./rsakey.pem

I followed https://github.com/OpenVPN/openvpn/issues/505#issuecomment-1960016502 and got following error from server side:

OpenSSL: error:02000088:rsa routines::salt length check failed:expected: 32 retrieved: 222

[gotthardp]

Based on OpenVPN logs posted by OP to OpenVPN/openvpn#505 this appears to be caused by TPM at the client side using max salt length for RSAPSS (222 in this particular case) while OpenSSL at server side expects the salt length to match that of digest (32 here) for TLS 1.3.

The TPM2.0 specification (Part 1, Section B.7) says: For both restricted and unrestricted signing keys, the random salt length will be the largest size allowed by the key size and message digest size. I am not sure the TPM2.0 can do shorter salt lengths.

[selvanair]

TPM2 specs on RSAPSS salt length have changed over time. Latest version says (quoting from Rev. 01.83, 25 Jan 2024, part 1, section B7, p. 264)

For both restricted and unrestricted signing keys, the random salt length is the largest size allowed by FIPS 186-5.

NOTE: Page 264 TPM implementations from prior to the publication of FIPS 186-4 (prior to TPM rev 1.63), which introduced the salt length limitation, may use the largest size allowed by the key size and message digest size.

Indeed on my Lenovo laptop (STM chip, spec revision 1.38), it signs with salt length = digest length. So it seems to depend on what is implemented in the firmware. Unfortunately not user selectable, it seems.