Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/rsa: allow hash.Hash for OAEP and MGF1 to be specified independently #19974

Open
nmiyake opened this issue Apr 14, 2017 · 9 comments
Open

crypto/rsa: allow hash.Hash for OAEP and MGF1 to be specified independently #19974

nmiyake opened this issue Apr 14, 2017 · 9 comments

Comments

@nmiyake
Copy link

@nmiyake nmiyake commented Apr 14, 2017

rsa.EncryptOAEP and rsa.DecryptOAEP both take a hash.Hash as input, and this hash function is used as the hash function for both OAEP and the MGF1 XOR. However, an option should be provided to specify the hash function for OAEP and MGF1 separately, as it is permissible for the hash functions for these two operations to be different.

This is pertinent for compatibility with other languages and RSA implementations, as the Sun JDK's implementation of the RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING provider uses SHA-256 for OAEP but SHA-1 for MGF1. As it currently stands, the rsa package in Go is not compatible with this encryption mode in Java.

For reference, the OpenSSL API also allows for the hash functions for OAEP and MGF1 to be specified separately: https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_oaep.c#L44, const EVP_MD *md, const EVP_MD *mgf1md.

@andybons
Copy link
Member

@andybons andybons commented Apr 11, 2018

@brandonweeks
Copy link

@brandonweeks brandonweeks commented Sep 5, 2018

As another data point, Android P has introduced usage of RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING.

https://developer.android.com/reference/android/security/keystore/WrappedKeyEntry

@shuxiao9058
Copy link

@shuxiao9058 shuxiao9058 commented May 7, 2019

the same issue.

@ribeiroit
Copy link

@ribeiroit ribeiroit commented Sep 11, 2019

Hi guys, I could help to implement the resolution for this issue, but I need your help to decide what's the best scenario for this.

Do you think the OEAPOptions is the best way?

Thank you

@FiloSottile
Copy link
Contributor

@FiloSottile FiloSottile commented Sep 12, 2019

OAEP is one of those unfortunate standards with a million parameters, which the Go standard library intentionally culls to a reasonable subset. For example, there is no good reason I know of to use different hashes at different stages of the algorithm.

On balance, I'm mostly ok with adding a field to OEAPOptions for decryption, as it won't disturb common users. However, adding a whole new function would be more invasive, and I don't think it would be worth it.

Would having support for independent hashes only for decryption make sense for your use cases, or would it be useless without encryption? (It makes sense to me also because the library is already asymmetrical due to crypto.Decrypter not having an encryption counterpart, and decryption is more likely to be about compatibility with a third party.)

@ribeiroit
Copy link

@ribeiroit ribeiroit commented Sep 13, 2019

I got your point, but thinking in interoperability maybe is the deal here. I think that it could reduce the fricction along another implementations. As the use case that I exposed related to android.

I think that makes sense use for both encrypt/decrypt.

Well, this is my understood at reading RFC 3447, starting chapter "7. Encryption schemes" and keeping up beyond this section. But, looking to the implementation that we have at the golang, I think that is a gonna be just a decision to update of the usage context and allow the encryption besides the decryption.

Thanks

sakjur added a commit to sakjur/go that referenced this issue Nov 11, 2019
Android and Java sometimes uses separate hash functions for the OAEP digest and
MGF1 mask generating function. By allowing the OAEPOption to support overriding
the mask generating function's hash algorithm it is possible to support
decryption of RSA-OAEP payloads generated with such a configuration.

Fixes golang#19974
sakjur added a commit to sakjur/go that referenced this issue Nov 11, 2019
Android and Java sometimes uses separate hash functions for the OAEP digest
and MGF1 mask generating function. By allowing the OAEPOption to support
overriding the mask generating function's hash algorithm it is possible to
support decryption of RSA-OAEP payloads generated with such a configuration.

Fixes golang#19974
@vieiramanoel
Copy link

@vieiramanoel vieiramanoel commented Nov 10, 2020

Update on this? Saw @sakjur commits but I couldn't find any PRs related

@sakjur
Copy link

@sakjur sakjur commented Nov 10, 2020

@vieiramanoel That was mostly an experiment that didn't lead anywhere and I later ended up not needing to complete 🙂 I'm not sure if whatever I have in my branch works at all, and it was mostly an accident that my WIP commits ended up being linked from here.

@varunkumark1997
Copy link

@varunkumark1997 varunkumark1997 commented Dec 30, 2020

Any Update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants