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

Michael StJohns mstjohns at comcast.net
Tue Mar 23 21:26:06 UTC 2021


On 3/22/2021 5:43 PM, Valerie Peng 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

> PR: https://git.openjdk.java.net/jdk/pull/2404

KeyWrapCipher.java:

>       /**
> 212      * Sets the padding mechanism of this cipher. Currently, only
> 213      * "NoPadding" scheme is accepted for this cipher.
> 214      *
> 215      * @param padding the padding mechanism
> 216      *
> 217      * @exception NoSuchPaddingException if the requested padding mechanism
> 218      * does not match the supported padding scheme
> 219      */
> 220     @Override
> 221     protected void engineSetPadding(String padding)
> 222             throws NoSuchPaddingException {
> 223         if ((this.padding == null && !"NoPadding".equalsIgnoreCase(padding)) ||
> 224                 this.padding instanceof PKCS5Padding &&
> 225                 "PKCS5Padding".equalsIgnoreCase(padding)) {
> 226             throw new NoSuchPaddingException();
> 227         }
> 228     }

Shouldn't this be rejecting PKCS5Padding?

Actually, I keep wondering why this isn't  AES/KW/NoPadding, 
AES/KW/KWPPadding and AES/KW/AutoPadding where the latter doesn't take a 
user provided IV, but figures out which of the two default IV values to 
use based on whether the input is a multiple of the blocksize or not?

Decrypting is similar - do the decryption, and check which IV you get to 
figure out padded or not padded.

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210323/0372393b/attachment.htm>


More information about the security-dev mailing list