On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng <valer...@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. Current impl takes account into RFC 3394 (Sept 2002), RFC 5649 (Aug 2009), NIST 800-38F (Dec 2012) and PKCS#11 v3.0 Current Mech Spec (June 2020) and tries to support them all. If solely basing on RFC 3394/5649, then AES KW and KWP cipher should just supports key wrap/unwrap but not enc/dec. The main reason that I added the support for alternative iv and enc/dec is more for NIST 800-38F which states that KW/KWP can be used for general data protection as well and PKCS#11 v3.0 which lists 3 mechanisms mapping to java's AES using KW, AES using KW and PKCS5Padding and AES using KWP. These 3 mechanisms supports all 4, i.e. enc/dec/wrap/unwrap, as well custom IVs (8-byte for KW and 4-byte for KWP). Naming can be a very subjective matter and putting it aside, I don't see why KW and KWP should not allow custom IVs? Isn't hardcoded values less secure or fragile in general? ------------- PR: https://git.openjdk.java.net/jdk/pull/2404
