KWP instead of AESWrap

[Michael StJohns]

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
>
> -- 
> http://bernd.eckenfels.net

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: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200624/8b0419d4/attachment.htm>