RSA_PADDING_ADD_PKCS1_TYPE_1(3SSL)

📦

version 4.0.3 · 14 versions

💖 RSA_PADDING_ADD_PKCS1_TYPE_1(3SSL) — the OpenSSL padding girlies 💖

okay bestie, sit DOWN, because today we're talking about the RSA_padding_* family from OpenSSL, aka the little crew of functions that make your RSA blocks look cute and properly formatted before they go out into the world. ✨ This is the 3SSL manual page, so you already know it's giving "official docs but make it understandable." 🎀

🌸 NAME 🌸

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 — asymmetric encryption padding 🦋

✨ SYNOPSIS ✨

#include <openssl/rsa.h>

real talk, 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 — check openssl_user_macros(7) for the deets:

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 💅

Every single function on this page is deprecated. no cap. Applications should use the EVP PKEY APIs instead, periodt. 💀

So here's the tea, bestie: the RSA_padding_xxx_xxx() functions get called from the RSA encrypt, decrypt, sign and verify functions. Normally? You should NOT be calling them from your application programs. They're backstage crew, not main characters. 🙈

However (and this is the plot twist 🎀), they can also be called directly to implement padding for other asymmetric ciphers. And specifically, RSA_padding_add_PKCS1_OAEP() and RSA_padding_check_PKCS1_OAEP() may be used in an application combined with RSA_NO_PADDING in order to implement OAEP with an encoding parameter. iconic behaviour honestly.

Here's how the add functions work: 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. Simple. Clean. Slay. ✨

The following encoding methods are implemented:

🌈 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

okay so this next part is IMPORTANT, bestie, don't skip it 🫶

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. so like. keep your RNG hydrated. 💧

Now for the check girlies: 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. ngl that's a handy little detail. 😌

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 eating, fr fr. ✨

🎀 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).

🚨 WARNINGS 🚨 — read this part twice, bestie, I'm serious

The result of RSA_padding_check_PKCS1_type_2() is exactly the information which is used to mount a classical Bleichenbacher padding oracle attack. That is not a vibe. That is not a glitch. That is an inherent weakness in the PKCS #1 v1.5 padding design. 😭

So, what do we do about it? Prefer PKCS1_OAEP padding. full stop.

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 too. And if the plaintext is rejected, it must be kept secret which of the checks caused the application to reject the message. 🤫

And do NOT — I repeat, 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. that's the whole ballgame, no cap. 💀

You should prefer the use of EVP PKEY APIs for PKCS#1 v1.5 decryption as they implement the necessary workarounds internally. let them carry the emotional load for you, bestie. 🫶

📜 HISTORY 📜

All of these functions were deprecated in OpenSSL 3.0.

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>.

okay that's the whole page, bestie, you ate that 💅✨ this masterpiece of documentation is from OpenSSL 4.0.3, dated 2026-09-29, and it lives under the name RSA_PADDING_ADD_PKCS1_TYPE_1(3SSL). go forth and pad responsibly, mwah 🎀🦋💖

📦 where this page comes from

ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 · Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms

RSA_PADDING_ADD_PKCS1_TYPE_1(3SSL)