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
