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. Good points, Mike! Thank you! > _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on > [security-dev](mailto:security-...@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. > 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. 2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1 of RFC 3394. 3. Use a fixed IV for KWP, as described in section 3of RFC 5649. > 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. 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
