Broken Logic in master:core/src/main/java/org/bouncycastle/crypto/engines/RFC5649WrapEngine.java about bc-java HOT 4 CLOSED

I've done an initial investigation on this, sorry, but I am unable to understand what the error is. It sounds like you are trying to use the RFC5649 engine to unwrap unpadded data. Would you provide some details of what the error actually is?

from bc-java.

My apologies I should have clarified the problem. So my situation is a case where the key may or may not be at length which is a multiple of 64 bits. As per RFC5649 is it stated: "This document specifies a padding convention for use with the AES Key
Wrap algorithm specified in RFC 3394. This convention eliminates the
requirement that the length of the key to be wrapped be a multiple of
64 bits, allowing a key of any practical length to be wrapped."

Which brings me to the implementation. Line 184 - 186 has:

// Otherwise, unwrap as per RFC 3394 but don't check IV the same way
            decrypted = rfc3394UnwrapNoIvCheck(in, inOff, inLen);
            paddedPlaintext = decrypted;

This is all fine and well, however the code proceeds to check the IV as described by "RFC5649 Section 3. Alternative Initial Value", rather than as described by RFC3394 Section 2.2.3.

Instead of copying the unwrap method in RFC3394WrapEngine as rfc3394UnwrapNoIvCheck, the code should defer to the RFC3394WrapEngine and return from where n != 2.

I would be more than happy to contribute to this. May I be given the permissions to submit a pull request with the changes?

from bc-java.

I think you've misunderstood the code - RFC3394 is a different algorithm, in NIST parlance AES KW, RFC 5649 is AES KWP. The reference concerning the IV is about how it's extracted from the encrypted stream for comparison (to make it clearer - don't check the IV the same way refers to "don't check it the same way as RFC 3394"). If you are wrapping keys that may or may not be 64 bits just use KWP.

from bc-java.

I see what you are saying here, I should have paid closer attention to "Otherwise, apply Steps 1 and 2 of the unwrapping process specified
in Section 2.2.2 of [AES-KW2] to the n+1 64-bit ciphertext blocks,
{C[0], C[1], ..., C[n]}, and to the KEK, K." in https://tools.ietf.org/html/rfc5649#section-3 However, it might be less confusing to just use the Step 1 and 2 implementation from RFC3394WrapEngine for added clarity, anyways thanks for double checking.

from bc-java.