RSA_PADDING_ADD_PKCS1_TYPE_1(3ossl)

πŸ’– RSA_PADDING_ADD_PKCS1_TYPE_1 πŸ’– (that's the manpage name, section 3ossl, from the OpenSSL fam)

okay bestie, sit down, hydrate, because we're about to talk about padding and honestly it's giving "important lore you didn't ask for but absolutely need". This page covers:

  • RSA_padding_add_PKCS1_type_1
  • RSA_padding_check_PKCS1_type_1
  • RSA_padding_add_PKCS1_type_2
  • RSA_padding_check_PKCS1_type_2
  • RSA_padding_add_PKCS1_OAEP
  • RSA_padding_check_PKCS1_OAEP
  • RSA_padding_add_PKCS1_OAEP_mgf1
  • RSA_padding_check_PKCS1_OAEP_mgf1
  • RSA_padding_add_none
  • RSA_padding_check_none

and the whole vibe of the page is asymmetric encryption padding ✨


✨ SYNOPSIS ✨

first things first, you gotta include the header:

#include <openssl/rsa.h>
⚠️ okay so ALL of these functions have been deprecated since OpenSSL 3.0 😭 and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value β€” peep openssl_user_macros(7) for the deets.

here's the full cast of characters, verbatim, no cap:

int RSA_padding_add_PKCS1_type_1(unsigned char *to, int tlen,
                                 const unsigned char *f, int fl);

int RSA_padding_check_PKCS1_type_1(unsigned char *to, int tlen,
                                   const unsigned char *f, int fl, int rsa_len);

int RSA_padding_add_PKCS1_type_2(unsigned char *to, int tlen,
                                 const unsigned char *f, int fl);

int RSA_padding_check_PKCS1_type_2(unsigned char *to, int tlen,
                                   const unsigned char *f, int fl, int rsa_len);

int RSA_padding_add_PKCS1_OAEP(unsigned char *to, int tlen,
                               const unsigned char *f, int fl,
                               const unsigned char *p, int pl);

int RSA_padding_check_PKCS1_OAEP(unsigned char *to, int tlen,
                                 const unsigned char *f, int fl, int rsa_len,
                                 const unsigned char *p, int pl);

int RSA_padding_add_PKCS1_OAEP_mgf1(unsigned char *to, int tlen,
                                    const unsigned char *f, int fl,
                                    const unsigned char *p, int pl,
                                    const EVP_MD *md, const EVP_MD *mgf1md);

int RSA_padding_check_PKCS1_OAEP_mgf1(unsigned char *to, int tlen,
                                      const unsigned char *f, int fl, int rsa_len,
                                      const unsigned char *p, int pl,
                                      const EVP_MD *md, const EVP_MD *mgf1md);

int RSA_padding_add_none(unsigned char *to, int tlen,
                         const unsigned char *f, int fl);

int RSA_padding_check_none(unsigned char *to, int tlen,
                           const unsigned char *f, int fl, int rsa_len);

🌸 DESCRIPTION 🌸

okay so, the headline: every single function on this page is deprecated πŸ’€. Apps should be using the EVP PKEY APIs instead. periodt.

The RSA_padding_xxx_xxx() girlies get called from the RSA encrypt, decrypt, sign and verify functions. So normally? You should not be calling them from your application programs. They're backstage crew, not main characters πŸŽ€.

BUT β€” and this is the plot twist β€” you can call them directly to implement padding for other asymmetric ciphers. RSA_padding_add_PKCS1_OAEP() and RSA_padding_check_PKCS1_OAEP() can be used in an application combined with RSA_NO_PADDING in order to implement OAEP with an encoding parameter. slay πŸ’…

So here's how the add side works: RSA_padding_add_xxx() encodes fl bytes from f so as to fit into tlen bytes and stores the result at to. An error occurs if fl does not meet the size requirements of the encoding method. (vibe check failed, sorry babe 😭)

the encoding methods, ranked πŸ†

  • PKCS1_type_1 β€” PKCS #1 v2.0 EMSA-PKCS1-v1_5 (PKCS #1 v1.5 block type 1); used for signatures
  • PKCS1_type_2 β€” PKCS #1 v2.0 EME-PKCS1-v1_5 (PKCS #1 v1.5 block type 2)
  • PKCS1_OAEP β€” PKCS #1 v2.0 EME-OAEP
  • none β€” simply copy the data (the "no thoughts, head empty" option 🫢)
πŸ”₯ RNG ALERT πŸ”₯ The random number generator must be seeded prior to calling RSA_padding_add_xxx(). And if the automatic seeding or reseeding of the OpenSSL CSPRNG fails due to external circumstances (see RAND(7)), the operation will fail. not me being dramatic but like, seed your RNG bestie.

the check side πŸ”

RSA_padding_check_xxx() verifies that the fl bytes at f contain a valid encoding for a rsa_len byte RSA key in the respective encoding method and stores the recovered data of at most tlen bytes (for RSA_NO_PADDING: of size tlen) at to.

For RSA_padding_xxx_OAEP(), p points to the encoding parameter of length pl. p may be NULL if pl is 0. πŸ‘‘

For RSA_padding_xxx_OAEP_mgf1(), md points to the md hash β€” if md is NULL that means md=sha1 β€” and mgf1md points to the mgf1 hash β€” if mgf1md is NULL that means mgf1md=md. defaults on defaults, iconic 🌈


⭐ RETURN VALUES ⭐

  • The RSA_padding_add_xxx() functions return 1 on success, 0 on error.
  • The RSA_padding_check_xxx() functions return the length of the recovered data, -1 on error.

Error codes can be obtained by calling ERR_get_error(3). go get your receipts 🧾


🚨 WARNINGS 🚨 (bestie please read this one)

πŸ’€ The result of RSA_padding_check_PKCS1_type_2() is exactly the information which is used to mount a classical Bleichenbacher padding oracle attack. This is an inherent weakness in the PKCS #1 v1.5 padding design.

Not a bug, not a skill issue β€” it's inherent to the design. So:

  • Prefer PKCS1_OAEP padding. like, strongly. πŸ’œ
  • If that is not possible, the result of RSA_padding_check_PKCS1_type_2() should be checked in constant time if it matches the expected length of the plaintext, and additionally some application specific consistency checks on the plaintext need to be performed in constant time.
  • If the plaintext is rejected, it must be kept secret which of the checks caused the application to reject the message. no leaking, no snitching 🀫
  • Do not remove the zero-padding from the decrypted raw RSA data which was computed by RSA_private_decrypt() with RSA_NO_PADDING, as this would create a small timing side channel which could be used to mount a Bleichenbacher attack against any padding mode including PKCS1_OAEP. (yes, even the good one. leave the zero-padding alone!! πŸ™ˆ)
🫢 You should prefer the use of EVP PKEY APIs for PKCS#1 v1.5 decryption as they implement the necessary workarounds internally. the workarounds are in there, bestie. let them cook.

πŸ‘€ SEE ALSO πŸ‘€

RSA_public_encrypt(3), RSA_private_decrypt(3), RSA_sign(3), RSA_verify(3), RAND(7)


πŸ¦‹ HISTORY πŸ¦‹

All of these functions were deprecated in OpenSSL 3.0. yeah. all of them. every last one. 😭


Copyright 2000-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


and that's the page!! πŸ’– this was OpenSSL 3.5.9, dated 2026-09-2, RSA_PADDING_ADD_PKCS1_TYPE_1(3ossl) β€” stay padded, stay constant-time, and go use the EVP PKEY APIs fr fr πŸŽ€βœ¨

πŸ“¦ where this page comes from