KWP instead of AESWrap

[Valerie Peng]

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

Thanks for the feedback,

Valerie

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
>>
>> -- 
>> 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/30510f9c/attachment.htm>