Repository navigation
Treat a wrong-length unwrapped CEK like an unwrap failure in jwe.decrypt - #428
Open
neeraj1235476 wants to merge 1 commit into
Open
neeraj1235476 wants to merge 1 commit into
neeraj1235476 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
jwe.decryptsubstitutes a random CEK whenunwrap_keyraises, but a CEK that unwraps cleanly is never checked against the lengthencrequires. WithRSA1_5, a ciphertext that has valid PKCS#1 v1.5 padding but the wrong payload length fails withKey must be 256 bit for alg A256GCM, while bad padding falls through to the random CEK and fails withInvalid JWE Auth Tag. That difference is a Bleichenbacher padding oracle on the recipient's RSA key. It is clean with thersabackend and pre-3.2 OpenSSL. With implicit rejection in newer OpenSSL it is narrower but still present. RFC 7516 section 11.5 says the recipient must not distinguish format, padding and length errors, and the existing comment indecryptalready quotes that.The random-CEK substitution now runs after the unwrap and also replaces a CEK whose length doesn't match
enc, so all three cases fail identically and still go through content decryption. The new test wraps a 16-byte CEK underRSA1_5withencA256GCMand expects the auth tag error. It fails on master with the key-length error.