Is there any package or library avaiable in flutter for performing rsa oaep(sha 256 and mgf1)?

in java, using bouncy castle library we perform rsa oaep encryprtion with oaep parameters like sha256 and mgf1.

But in flutter, we have only library for rsa-oaep, sha256 sperately. so is there any package that specifies oaep encryption with parametrs specific like, rsa-oaep(sha 256 and mgf1)?

I found this, stating that PointyCastle's OAEP implementation is not compatible with RSAES-OAEP v2.1 or later (see here):

> RSAES-OAEP v2.0
>
> This implementation is based on the RSAES-OAEP (RSA Encryption Scheme - Optimal Asymmetric Encryption Padding) as specified in section 7.1 of RFC 2437 PKCS #1: RSA Cryptography Specifications Version 2.0.
>
> Important: this is not compatible with RSAES-OAEP v2.1 or later (as
> specified in RFC 3447, RFC 8017, etc.) Those newer versions have an
> extra 0x00 byte at the beginning of the encoded message (EM) that is
> passed to the RSA encryption primitive. Therefore, this implementation
> is incompatible with it, since this is an implementation of v2.0 which
> does not have that 0x00 byte. A breaking change in the standard!
>
> Currently, this implementation has the following restrictions:
>
> - the hash function is hard-coded to be SHA-1 or SHA-256;
> - the mask generation function is hard-coded to MGF1; and
> - it cannot accept any encoding parameters (that is, P is always empty)

It is true that in RFC3447 (from Feb 2003) and later RFCs, in contrast to RFC2437 (from Oct 1998), an additional leading 0x00 byte is used, cf. RFC2437, sec. 9.1.1.1, step 11, and RFC3447, sec. 7.1.1, step 2i.

I.e. in RFC2437 EM is defined as maskedSeed || maskedDB with a size of k-1 bytes and in RFC3447 as 0x00 || maskedSeed || maskedDB with a size of k bytes, where k is the key size in bytes (i.e. the size of the modulus in bytes).

However, on closer inspection, this difference does not appear to result in an incompatibility between RFC2437 and the later RFCs:

• During encryption, the byte sequence EM is next converted to a positive integer m, described in RFC as OS2IP (Octet Stream to Integer Primitive), see e.g. RFC3447, sec. 4.2. Here, the byte sequence is interpreted in big endian order, so that the additional 0x00 byte contributes the additional term 0x00 * 256^k-1. This is 0, so that in both cases the same integer results. Since the remaining steps are identical, the same ciphertext results for both RFCs.

• During decryption, the integer m is converted to a byte sequence EM in big endian order, described in the RFCs as I2OSP (Integer to Octet Stream Primitive), see e.g. RFC3447, sec. 4.1. Here, consistent with encryption, in RFC2437 the integer is converted to k-1 bytes (RFC2437, sec. 7.1.2, step 4) and in RFC3447 to k bytes (RFC3447, sec. 7.1.2, step 2c), both differing only in the additional front byte of the k bytes sequence (which is 0x00 in the case of a valid decryption). From the identical rest, maskedSeed and maskedDB are determined and since the remaining steps are identical, the same decrypted value results for both RFCs.

So there seems to be no breaking change from RFC2437 to RFC3447 (or later).

It is still possible that an incompatibility is caused by the implementation itself. However, there is no evidence for this:
In my tests, ciphertexts generated with the Dart/PointyCastle implementation were successfully decrypted with Java/JDK17 and online tools (e.g. CyberChef, since 2016). Conversely, ciphertexts generated with Java/JDK17 were successfully decrypted with Dart/PointyCastle.

All in all, this breaking change does not seem to exist. Possibly the RFCs were misinterpreted or there was an implementation issue that has been fixed in the meantime without removing the warning.

So you could use the PointyCastle implementation for cross-platform encryption/decryption with Java. Note that Java (SunJCE and BouncyCastle) allows to specify different digests for the OAEP and MGF1 digest, while Dart/PointyCastle seems to allow only identical digests for the OAEP and MGF1 digest.