Awesome:

For Android Keystore, SHA-1 is used for the MGF1 digest, whereas for other Android cryptographic providers, the two digests are the same.

--https://developer.android.com/guide/topics/security/cryptography#oaep-mgf1-digest [emphasis added]

It seems like the easy solution here is to add a MGF1Hash hash.Hash field to OAEPOptions, and then fall back to EncryptOAEP's hash parameter when it's nil.

/cc @agl @FiloSottile

RFC 2437 theoretically allows maskGenFunc to not even be MGF1-based. So an alternative option here would be to add a Mask func(out, seed []byte) field to OAEPOptions.

This would probably merit exposing mgf1XOR.

Alright!

I'd like to suggest this hypotesis as a valid implementation, but I've read that OAEPOptions was just related to decrypt function.

So I changed my mind and I decided to add an optional parameter at the end of the function EncryptOEAP to be not confused.

As I'm new here, my question is that should I submit a PR with the resolution, or assume that you gonna fix that.

Thanks for the answer.

I'd like to suggest this hypotesis as a valid implementation, but I've read that OAEPOptions was just related to decrypt function.

Yes, you're right. Sorry, I didn't look closely enough at the API to see how OAEPOptions is actually used.

I think OAEPOptions will probably need to be extended, but then EncryptOAEP and DecryptOAEP also need variants that take the additional MGF parameter (either simply the underlying hash to use with MGF1, or a substitute for MGF1 entirely).

For backwards compatibility though, we can't add parameters to existing functions.

Duplicate of #19974