KWP instead of AESWrap

Valerie Peng valerie.peng at
Wed Jun 24 23:37:21 UTC 2020

Yes, the mode suggestion sounds reasonable. I will include all of the 
suggestions into the RFE for completeness sake.

Thanks for the feedback,


On 6/24/2020 2:58 PM, Michael StJohns wrote:
> On 6/24/2020 4:58 PM, Bernd Eckenfels wrote:
>> Hello,
>> 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?
>> Gruss
>> Bernd
>> -- 
> You probably know that BouncyCastle implements KWP?
> 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.
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the security-dev mailing list