RSA_PADDING_ADD_PKCS1_TYPE_1(3ossl)

πŸ“¦
version 15.1 Β· 2 versions
, in freebsd 15.1

πŸ’… RSA_PADDING_ADD_PKCS1_TYPE_1 (3ossl) πŸ’…

okay so bestie, welcome to the OpenSSL manual, section 3ossl β€” this one's all about asymmetric encryption padding and it is a lot, but we're gonna get through it together, hand in hand, no cap 🫢


✨ 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 β€” literally the whole padding squad, all ten of them, here to do asymmetric encryption padding. πŸ’–


🌸 SYNOPSIS 🌸

First things first, you gotta pull in the header:

#include <openssl/rsa.h>
🚨 Important vibe check: the following functions have been deprecated since OpenSSL 3.0, and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value β€” see openssl_user_macros(7) for the deets.

Here's the whole lineup, verbatim, no edits, we do not touch the code in this house:

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 πŸ¦‹

So. Every single function on this page is deprecated. Not me being dramatic, that's just the facts πŸ’€. Applications should instead use the EVP PKEY APIs. That's the upgrade, bestie, take it.

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 application programs. They're backstage crew, not main characters.

But β€” and this is the fun part β€” you can also call them directly to implement padding for other asymmetric ciphers. And 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. Slay, customizability. ✨

RSA_padding_add_xxx() encodes fl bytes from f so as to fit into tlen bytes, and stores the result at to. If fl does not meet the size requirements of the encoding method β€” error. Simple as that.

πŸŽ€ 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" of padding)

πŸ”₯ the RNG tea πŸ”₯

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 up for debate, it's just how it is. 😭

🧚 the check functions 🧚

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, but make them your defaults, iykyk.


⭐ 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 πŸ’€

okay bestie, sit down, this is the serious part, and I mean it.

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, a design weakness. Prefer PKCS1_OAEP padding. Periodt.

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. Like, do not leak that. Do not give the attacker a hint. Do not pass go.

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. πŸ™ˆ

And one more time for the people in the back: you should prefer the use of EVP PKEY APIs for PKCS#1 v1.5 decryption, as they implement the necessary workarounds internally. Let them handle it, king. πŸ‘‘


🌈 SEE ALSO 🌈

RSA_public_encrypt(3), RSA_private_decrypt(3), RSA_sign(3), RSA_verify(3), RAND(7) β€” go read these too, they're the supporting cast and they ate. πŸ’…


πŸ‘‘ HISTORY πŸ‘‘

All of these functions were deprecated in OpenSSL 3.0. That's the whole history section. Short and iconic.


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 whole page, bestie!! this was OpenSSL version 3.5.6, dated 2026-04-0, and honestly? she understood the assignment. now go use the EVP PKEY APIs, drink some water, and stay constant-time πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from