# Are RSA-PSS parameters standardized?

I wish to agree with a 3rd party on using RSA-PSS algorithm for a implementing a Digital Signature Scheme. I want to avoid selection of RSA parameters like salt length, hash algorithm etc at my side and share the required configuration parameters.

Instead I want to refer to a standard where all the parameters are already standardized so that we both can commonly refer to the same standard. We will perform signing at his side and verification at my side.

Are these parameters stardized by FIPS or IETF or ISO/IEC so that we can avoid a big deal of overhead? If yes, which standard deals with this?

Let's first get rid over two parameters that only have one option: the Mask Generation Function (MGF) and the trailer field. These can only be configured to MGF1 and 1 respectively in RFC 3447 which specifies RSA-PSS.

You won't find a generic standard that chooses one hash over the other for MGF1 because any hash will be considered secure, including the default (SHA-1). On the other hand, there will be many higher level protocols or applications that will have chosen one specific set of configuration parameters.

If we take a look at RFC 4055 where the PSS is used for X.509v3 certificates (the ones you will find used for TLS in e.g. your browser) we'll find that the configuration options can be indicated for a specific public key within a certificate:

RSASSA-PSS-params  ::=  SEQUENCE  {
hashAlgorithm      [0] HashAlgorithm DEFAULT
sha1Identifier,
mgf1SHA1Identifier,
saltLength         [2] INTEGER DEFAULT 20,
trailerField       [3] INTEGER DEFAULT 1  }


As you can see, all values have their default, so this would be an easy set of rules to comply with. Within certificates the public key and its parameters are signed, so the security of the parameters should be guaranteed.

However, there is one additional detail:

The maskGenAlgorithm field identifies the mask generation function. The default mask generation function is MGF1 with SHA-1. For MGF1, it is strongly RECOMMENDED that the underlying hash function be the same as the one identified by hashAlgorithm.

Of course that would mean changing the default by specifying the MaskGenAlgorithm and mgf1SHA1Identifier for field [1]: maskGenAlgorithm. As SHA-1 is considered broken and therefore not an option for hashAlgorithm, that means that another hash algorithm should be chosen.

As all other parameters are set, that means the hash function becomes the only configuration parameter.

Now as SHA-2 is in common use is it probably the best family of hash algorithms to choose from. SHA-224 and SHA-384 are simply shorter output functions of SHA-256 and SHA-512 and they don't make much sense for signatures. So that leaves the choice of one of the two. SHA-256 is used most and has hardware support on many chips. SHA-512 is using 64 bit operations and is both fast and secure on 64 bit chips.

For compatibility reasons and the hardware support I'd probably slightly favor SHA-256. It still has plenty of security and hashes data at over twice the speed using hardware support.

So there we are: SHA-256, MGF-1 with SHA-256, 20 byte salt and a trailer field set to 1. Just communicate this with your friend by explicitly describing it in your protocol and you're all set when it comes to PSS.

That just takes care of the PSS parameters. You'd also want to specify how you're going to trust the public key (oh dear, did I mention X.509 certificates?), and what (minimum) key size to use. Any key size of 3072 bits or over is OK, but I'd stick to 3072 bits which has the same security level as SHA-256's collision resistance at ~128 bits of security.

• FWIW TLS1.3 (RFC8446 4.2.3) goes a step further -- MGF1 hash must match message hash, and salt length must match that hash. For protocol signature (as opposed to certificate signature) TLS doesn't send the ASN.1 parameters at all, only a single 16-bit number that specifies PSS and the hash, plus a constraint on the cert containing the key. – dave_thompson_085 Feb 28 '20 at 3:31