How can I handle error "Unsupported OAEP encoding parameters source"?

0 votes
asked Jan 3, 2018 by christian.harter (250 points)

How can I handle errors when decrypting a mail?

1 Unsupported OAEP encoding parameters source
2 Unsupported OAEP hashing algorithm and mask generation algorithm combination

The sender insists that his emails are encrypted correctly. How can I proof this?

Thank you.

Applies to: Rebex Secure Mail
commented Jan 10, 2018 by Lukas Pokorny (123,890 points)
Thanks! We are almost finished with the hotfix release and we will most likely going to publish it tomorrow. Thanks for helping us make it more compatible! :-)
commented Jan 11, 2018 by Lukas Pokorny (123,890 points)
We just released Rebex Secure Mail 2017 R6.3 that includes both hotfixes:
The "unsupported hash algorithm combination" turned out to be more common than we expected, so we decided to include it as well.
commented Jan 17, 2018 by whasler (100 points)
I just updated to the new Release Rebex Secure Mail 2017 R6.3. But for mails of one of our customers I still get "Unsupported OAEP encoding parameters source".
As we also have a bouncycastle based java implementation in place, I now could reproduce the error with the following java OAEP parameters:
OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, new PSource.PSpecified("1234".getBytes()))
commented Jan 18, 2018 by whasler (100 points)
Sorry my fault, I was still using Rebex Secure Mail 2017 R6.2 after the Update to R6.3 everything works perfect.
commented Jan 18, 2018 by Lukas Pokorny (123,890 points)
Thanks for letting us know!

1 Answer

0 votes
answered Jan 3, 2018 by Lukas Pokorny (123,890 points)
edited Jan 11, 2018 by Lukas Pokorny
Best answer

The sender is most likely right. The first error was most likely triggered by a recently-discovered bug, while the second error is caused by a known limitation.

Update: This has been fixed in Rebex Secure Mail 2017 R6.3.

1) "Unsupported OAEP encoding parameters source" error occurs when the encrypted email used a non-empty input parameter (also known as label or P), which is a kind of salt for the OAEP calculations. This bug has been reported by another user few days ago. We have already fixed it and will release a hotfix shortly.
This issue was not detected by our automated interoperability tests because of lack of real-world test data - we have apparently only been testing messages with empty labels (which seems to be a default behavior in OpenSSL and GPG's gpgsm utility as well).

2) "Unsupported OAEP hashing algorithm and mask generation algorithm combination" error occurs when the hashing algorithm used to compute the hash of the label is different than the hashing algorithm used in the OAEP mask generation function.
This is actually correct as well. However, Windows cryptographic APIs do not support RSA/OAEP with non-matching hash algorithms, and we expected such messages to be very rare, so we decided not to initially support this.
However, based on your feedback, it looks like such messages might not actually be as rare as we hoped, so we will add support for it shortly as well. (Due to lack of support in Windows, we will have to use a custom implementation, which means it will not work private keys stored in Windows key storage unless they are exportable.)