RFR: 8248268: Support KWP in addition to KW [v7]

Sat May 22 23:32:43 UTC 2021

On 5/22/2021 1:57 PM, Xue-Lei Andrew Fan wrote:
> On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>
>>> This change updates SunJCE provider as below:
>>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation.
>>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>>
>>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class.
>>>
>>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>>>
>>> Thanks,
>>> Valerie
>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>>
>>   - Merge master into JDK-8248268
>>   - Minor update to address review comments.
>>   - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>     KWParameters and KWPParameters.
>>   - Refactor code to reduce code duplication
>>     Address review comments
>>     Add more test vectors
>>   - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>     AES/KWP/NoPadding
>>   - Restored Iv algorithm parameters impl.
>>   - 8248268: Support KWP in addition to KW
>>     
>>     Updated existing AESWrap support with AES/KW/NoPadding cipher
>>     transformation. Added support for AES/KWP/NoPadding and
>>     AES/KW/PKCS5Padding support to SunJCE provider.
> Good points, Mike!  Thank you!
>
>> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
>>> src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
>>>> 48:
>>>> 49:     public AESParameters() {
>>>> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
>>>> A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:
>> The mode is KW - it has a fixed length 8 byte non-iv integrity tag.???
>> KWP is a special case of KW where there's still an 8 byte tag, but part
>> of it is interpreted by KWP to figure out how much padding was
>> included.?? KW (AKA RFC3394) permits user (actually specification
>> specified) IV values.? KWP (aka RFC5649) does not.
>>
> Hm, I missed this point.  KW (RFC 3394) supports Alternative IV (AIV), while KWP is just a case about how to construct the alternative IV for KWP operations.

Yes.  Sorry if I wasn't clearer in earlier emails.

>
>> I'd treat KWP as a final (in the Java final sense) extension to KW with
>> a fixed AIV flag value and a defined interpretation for the 8 byte AIV
>> tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If
>> someone else wants to do something like KWP or even twiddle with the 4
>> byte AIV, let them do their own KW wrap around - which they should be
>> able to do that via the KW/NoPadding model by specifying their own AIV.?
>> That should improve interoperability by preventing some monkey see
>> monkey do errors.
>>
> I agreed.  Maybe, we could do:
> 1. Support Alternative IV for KW, for the flexibility as described in section 2.2.3.2 of RFC 3394.

I think that's acceptable.  Hmm... is it possible to make the set ICV 
call protected rather than public?   Generally, the defined ICVs match 
up with specific algorithm OIDS.  You shouldn't see a third one unless 
someone defines a brand new variant.  But you want to make it possible 
for someone to do an extension.

> 2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1 of RFC 3394.
Works.  Or see the above.
> 3. Use a fixed IV for KWP, as described in section 3of RFC 5649.
Yes.
>
>> This is sort of one reason I was arguing for AES/KW/KWPPadding rather
>> than AES/KWP/NoPadding.
>>
> I thought of the "AES/KW/KWPPadding" style as well.  The "AES/KWP/NoPadding" looks a little bit weird to me because there is padding while we call it with "NoPadding".
>
> KWP is not exactly like the traditional AES/CBC/PKCS5Padding, where the components could be treated separately.  The padding scheme of KWP impact the IV as well.  So it was arguable to me.

We keep referring to it as an IV  - but it isn't - it's an Integrity 
Check Value.  Unlike an IV, it doesn't inform the decryption stage, it's 
only checked after the decryption is complete.  (E.g. in a mode with an 
IV, you need to know the IV before you encrypt and before you decrypt).  
Then there's this from Section 6.3 of SP800-38F.

> Let S = ICV2|| [len(P)/8]32 || P|| PAD

Step 5 of the KWP-AE algorithm basically passes the A65959A6 value 
pre-prepended to the pad length both pre-pended to the padded data 
through to W().

The equivalent for KW-AE is step 2 which passes the ICV1 value in 
pre-pended to the plaintext.  (e.g. these are the inputs to W()).

The underlying function W() is doing what it does without any reference 
to the actual value of the ICV both on encrypt and decrypt.

So the differences between KWP and KW are actually in how the plain text 
data is marshalled  and unmarshalled and the checking they do on the 
decrypted ICVs, not in the actual cryptography.

>
> Finally I feel better of the "AES/KWP/NoPadding" when I read the NIST SP title again, "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping".  Maybe, it is an industry accepted notation to treat KWP as a block cipher mode.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2404

Think of it this way:  W() and W'() are the actual cryptographic actions 
that implement key wrapping - the mode if you will.  KW-AE and KWP-AE 
are the NoPadding and KWPPadding instantiations of that mode.

Another way of looking at that - KW-AE can't use a variant ICV. (Or at 
least I can't find a place where it's permitted - I was mistaken in 
including it above as the same as RFC3394).  If you're going to call it 
KWP/NoPadding and KW/NoPadding, then maybe you shouldn't support the 
provision of a different ICV as this isn't supported by SP800-38F.

*shrug*

I don't think that Java nomenclature and NIST nomenclature have to match 
up.  But ideally, Java nomenclature should try to be consistent amongst 
itself.  AES/KWP/NoPadding just sounds less right than AES/KW/KWPPadding.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210522/583ff57a/attachment.htm>