What salt should be used when generating TLS 1.3 CertificateVerify message?

Question

When signing handshake messages digest, the MGF1 function takes some salt value with same length as the digest has. But what content must be in salt's buffer?

I explored the source code of libnettle, especially method rsa_pss_sha256_verify_digest and found that salt which is used inside is 32 similar bytes - 0x22. Using this value I was able to generate a valid signature myself. But I found no information about the salt in any documentation. How is it actually generated for TLS 1.3 CertificateVerify message? Is this value fixed or depends on certificate or key...?

Answer 1

The salt should be generated randomly. This is how PSS encoding is defined: the salt length is an input, and the encoding process generates a random salt of the specified length. The PSS verification process treats the salt read from the signature as an input which can be an arbitrary string of the expected length.

The TLS 1.3 specification states that the salt length must be equal to the length of the hash. (That's the same algorithm used to hash the input and for the MGF — PSS recommends using the same hash, and TLS 1.3 mandates this.) PSS itself allows longer and shorter salts, but using the hash length is very common, even in contexts other than TLS 1.3 where the salt length is not mandated. The security proof of PSS is based on this common choice, but as far as I know there are no known weaknesses for using a shorter, even empty salt, or a non-random salt.

Choosing a non-random (or too short) salt for PSS can reveal the message, since it makes the message guessable from the signature. This is not a concern for a TLS handshake since the message itself contains a random input (ClientHello.random and ServerHello.random).