---
title: "RSA Signature/Verification"
source_url: https://dev.digicert.com/trustcore-sdk/crypto-interface/asymmetric-key-algorithms/rsa-signature-verification.html
---

The Crypto Interface supports padding modes PKCS #1 v1.5 and EMSA-PSS.

## PKCS #1 v1.5 padding mode


> **Important**
>
> The following RSA sign and verify APIs perform only the RSA signature encryption and decryption steps and do not perform any hashing or digest info constructions. The name `CRYPTO_INTERFACE_RSA_signMessageAux` is a misnomer left over for legacy purposes. The application is responsible for hashing the message and, if required, constructing the digest info object.


Once a digest info is stored in a buffer, `pDigestInfo` is created. The resulting signature may be obtained by calling:

```c
CRYPTO_INTERFACE_RSA_signMessageAux(pPrivKey, pDigestInfo, digestInfoLen, pSignature, NULL);
```

The size of the signature is the same as the key size in bytes, and the buffer `pSignature` must have enough space. Signing is deterministic and does not require an RNG.

To verify the signature, call:

```c
CRYPTO_INTERFACE_RSA_verifyDigest(pPubKey, pDigestInfo, digestInfoLen, pSignature, signatureLen, &isValid, NULL);
```

The same bytes of data, `pDigestInfo`, that were signed must be passed, regardless of whether it was a digest Info, a raw digest, or a short message. `isValid` is set to `TRUE` if the signature is valid, and `FALSE` otherwise.


> **Important**
>
> Ensure that both the return status is `OK` and `isValid` is equal to `TRUE` before accepting that the signature is valid.


## EMSA-PSS padding mode

For EMSA-PSS, use the following APIs, which expect the original message to be passed because hashing is performed internally as part of the EMSA-PSS routine:

```c
CRYPTO_INTERFACE_PKCS1_rsaPssSign(g_pRandomContext, pPrivKey, hashAlgo, MOC_PKCS1_ALG_MGF1, hashAlgo, pMessage, messageLen, saltLen, &pSignature, &signatureLen);

CRYPTO_INTERFACE_PKCS1_rsaPssVerify(pPubKey, hashAlgo, MOC_PKCS1_ALG_MGF1, hashAlgo, pMessage, messageLen, pSignature, signatureLen, saltLen, &vfy);
```

Parameters are mostly self-explanatory with some analogous to that of the OAEP APIs. Instead of a label, EMSA-PSS uses a salt randomly generated during the signing process. Typically, `saltLen` is 20 bytes, or the hash result length of the `hashAlgo` chosen. During verification, if a `saltLen` is passed, then that value is validated as part of the verification process. If the `saltLen` is unknown at verification time, `-1` may be passed, and the verification process skips validation. `vfy` is set to `0` if the signature is valid, and non-zero otherwise.


> **Important**
>
> Ensure that both the return status is `OK` and `vfy` is equal to `0` before accepting that the signature is valid. Also note that `vfy` is type `ubye4 *` and not `intBoolean *` that is defined in the PKCS #1 v1.5 verify API.


## Complete examples

Complete examples may be found at:

```
${MSS_SRC_PKG}/src/crypto_interface/example/crypto_interface_rsa_example.c
${MSS_SRC_PKG}/src/crypto_interface/example/crypto_interface_rsa_pss_example.c
```