-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
b26
-
generic
-
generic
Request submitted to OpenJDK security alias:
Initial request from Bernd Eckenfels <ecki@zusammenkunft.net>
JCE implements the AESWrap cipher, but it's does not offer the KWP mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W which is also used by AESWrap, however do to different initialisation vectors the existing implementation can not be used to implement the padded wrapping.
Is it possible to offer KWP as a special padding mode for AESWrap or have the W mode be it's own block mode so you can implement the padding externally?
Additional feedback from Michael StJohns <mstjohns@comcast.net>
Reading the comments in the AESWrapCipher code, this was created against the XML encryption standards even though the underlying code is a straight implementation of RFC3394.
Rather than twiddle with this current implementation and name mapping, it may make more sense to redo this as a normal <Alg>/<mode>/<padding> mapping. E.g. "AES/KeyWrap-NIST/NoPadding" or KWPPadding or AutoPadding rather than the current "AESWrap". That would then allow for "ChaCha20/KeyWrap-NIST/AutoPadding" and others.
I.e., copy the code from the current AESWrapCipher and convert it to a mode. More work now, less later. The AutoPadding would select the no padding if the encoded key size was a multiple of the block length, and the KWP padding if the encoded key size was not a multiple. Or read the IV to determine which for unwrapping.
Initial request from Bernd Eckenfels <ecki@zusammenkunft.net>
JCE implements the AESWrap cipher, but it's does not offer the KWP mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W which is also used by AESWrap, however do to different initialisation vectors the existing implementation can not be used to implement the padded wrapping.
Is it possible to offer KWP as a special padding mode for AESWrap or have the W mode be it's own block mode so you can implement the padding externally?
Additional feedback from Michael StJohns <mstjohns@comcast.net>
Reading the comments in the AESWrapCipher code, this was created against the XML encryption standards even though the underlying code is a straight implementation of RFC3394.
Rather than twiddle with this current implementation and name mapping, it may make more sense to redo this as a normal <Alg>/<mode>/<padding> mapping. E.g. "AES/KeyWrap-NIST/NoPadding" or KWPPadding or AutoPadding rather than the current "AESWrap". That would then allow for "ChaCha20/KeyWrap-NIST/AutoPadding" and others.
I.e., copy the code from the current AESWrapCipher and convert it to a mode. More work now, less later. The AutoPadding would select the no padding if the encoded key size was a multiple of the block length, and the KWP padding if the encoded key size was not a multiple. Or read the IV to determine which for unwrapping.
- csr for
-
JDK-8261910 Support KWP in addition to KW
-
- Closed
-
- relates to
-
JDK-8273255 Release Note: Fix Issues With the KW and KWP Modes of SunJCE Provider
-
- Closed
-
-
JDK-8268525 Some new memory leak after JDK-8248268 and JDK-8255557
-
- Resolved
-
-
JDK-8268621 SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers
-
- Resolved
-
-
JDK-8271745 Correct block size for KW,KWP mode and use fixed IV for KWP mode for SunJCE
-
- Closed
-
(2 links to)