Skip to content

[API Proposal]: Obsolete RSACryptoServiceProvider.Decrypt,Encrypt with fOAEP #113616

@vcsjones

Description

@vcsjones

Background and motivation

Inspired by #113555. I don't think we are quite in a position to obsolete RSACryptoServiceProvider entirely, but it would be nice if it were possible.

In lieu of that, we might want to consider obsoleting

  • public byte[] Encrypt(byte[] rgb, bool fOAEP)
  • public byte[] Decrypt(byte[] rgb, bool fOAEP)

With the recommendation to replace them with

  • public byte[] Encrypt(byte[] data, RSAEncryptionPadding padding)
  • public byte[] Decrypt(byte[] data, RSAEncryptionPadding padding)

The primary motivating factor here is that fOAEP: true means "OAEP SHA-1". Since this will always mean SHA-1, and SHA-1 is discouraged now, the right API should always be the one that accepts an RSAEncryptionPadding so that OAEP algorithm is not defaulted to SHA-1.

In other words, the bool is making the OAEP/MGF-1 hash algorithm non-apparent.

Developers would be expected to replace

  • Decrypt(data, fOAEP: true) ➡️ Decrypt(data, RSAEncryptionPadding.OaepSHA1)
  • Decrypt(data, fOAEP: false) ➡️ Decrypt(data, RSAEncryptionPadding.Pkcs1)
  • Encrypt(data, fOAEP: true) ➡️ Encrypt(data, RSAEncryptionPadding.OaepSHA1)
  • Encrypt(data, fOAEP: false) ➡️ Encrypt(data, RSAEncryptionPadding.Pkcs1)

API Proposal

namespace System.Security.Cryptography;

public partial sealed class RSACryptoServiceProvider {
+   [Obsolete("Encrypt and Decrypt on RSACryptoServiceProvider that accept a boolean value for OAEP are obsolete. Use an overload that accepts RSAEncryptionPadding.", DiagnosticId = "SYSLIBXXXX", UrlFormat = Obsoletions.SharedUrlFormat)]
    public byte[] Decrypt(byte[] rgb, bool fOAEP);
+   [Obsolete("Encrypt and Decrypt on RSACryptoServiceProvider that accept a boolean value for OAEP are obsolete. Use an overload that accepts RSAEncryptionPadding.", DiagnosticId = "SYSLIBXXXX", UrlFormat = Obsoletions.SharedUrlFormat)]
    public byte[] Encrypt(byte[] rgb, bool fOAEP);
}

API Usage

None.

Alternative Designs

If there is a "better" obsoletion for RSACryptoServiceProvider that we can pursue, I would be in favor of that.

Risks

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions