<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/22/2021 1:57 PM, Xue-Lei Andrew
Fan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng <a class="moz-txt-link-rfc2396E" href="mailto:valeriep@openjdk.org"><valeriep@openjdk.org></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Good points, Mike! Thank you!
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">_Mailing list message from [Michael StJohns](<a class="moz-txt-link-freetext" href="mailto:mstjohns@comcast.net">mailto:mstjohns@comcast.net</a>) on [security-dev](<a class="moz-txt-link-freetext" href="mailto:security-dev@mail.openjdk.java.net">mailto:security-dev@mail.openjdk.java.net</a>):_
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>Yes. Sorry if I wasn't clearer in earlier emails. <br>
</p>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>I think that's acceptable. Hmm... is it possible to make the set
ICV call protected rather than public? Generally, the defined
ICVs match up with specific algorithm OIDS. You shouldn't see a
third one unless someone defines a brand new variant. But you
want to make it possible for someone to do an extension.<br>
</p>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">
2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1 of RFC 3394.</pre>
</blockquote>
Works. Or see the above.<br>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">
3. Use a fixed IV for KWP, as described in section 3of RFC 5649.</pre>
</blockquote>
Yes.<br>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">This is sort of one reason I was arguing for AES/KW/KWPPadding rather
than AES/KWP/NoPadding.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>We keep referring to it as an IV - but it isn't - it's an
Integrity Check Value. Unlike an IV, it doesn't inform the
decryption stage, it's only checked after the decryption is
complete. (E.g. in a mode with an IV, you need to know the IV
before you encrypt and before you decrypt). Then there's this
from Section 6.3 of SP800-38F.<br>
</p>
<p>
<blockquote type="cite"><span style="left: 180px; top: 650.4px;
font-size: 20px; font-family: serif; transform:
scaleX(0.992101);" dir="ltr">Let </span><span style="left:
211.4px; top: 650.4px; font-size: 20px; font-family: serif;
transform: scaleX(0.930714);" dir="ltr">S </span><span
style="left: 226.6px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(0.994882);" dir="ltr">=
</span><span style="left: 242.8px; top: 650.4px; font-size:
20px; font-family: serif; transform: scaleX(0.933527);"
dir="ltr">ICV</span><span style="left: 275px; top: 650.4px;
font-size: 20px; font-family: serif;" dir="ltr">2</span><span
style="left: 285px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(1.00142);" dir="ltr"> ||
[len(</span><span style="left: 340.8px; top: 650.4px;
font-size: 20px; font-family: serif;" dir="ltr">P</span><span
style="left: 353px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(0.997115);" dir="ltr">)/8]</span><span
style="left: 382px; top: 657.95px; font-size: 13.4px;
font-family: serif; transform: scaleX(0.9992);" dir="ltr">32 </span><span
style="left: 398.8px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(0.969231);" dir="ltr">||
</span><span style="left: 411.4px; top: 650.4px; font-size:
20px; font-family: serif;" dir="ltr">P</span><span
style="left: 423.6px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(1);" dir="ltr"> || </span><span
style="left: 441.8px; top: 650.4px; font-size: 20px;
font-family: serif; transform: scaleX(1.01667);" dir="ltr">PAD</span></blockquote>
</p>
<p><br>
Step 5 of the KWP-AE algorithm basically passes the A65959A6 value
pre-prepended to the pad length both pre-pended to the padded data
through to W().<br>
</p>
<p>The equivalent for KW-AE is step 2 which passes the ICV1 value in
pre-pended to the plaintext. (e.g. these are the inputs to W()).</p>
<p>The underlying function W() is doing what it does without any
reference to the actual value of the ICV both on encrypt and
decrypt.</p>
<p>So the differences between KWP and KW are actually in how the
plain text data is marshalled and unmarshalled and the checking
they do on the decrypted ICVs, not in the actual cryptography.<br>
</p>
<blockquote type="cite"
cite="mid:70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com">
<pre class="moz-quote-pre" wrap="">
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: <a class="moz-txt-link-freetext" href="https://git.openjdk.java.net/jdk/pull/2404">https://git.openjdk.java.net/jdk/pull/2404</a>
</pre>
</blockquote>
<p>Think of it this way: W() and W'() are the actual cryptographic
actions that implement key wrapping - the mode if you will. KW-AE
and KWP-AE are the NoPadding and KWPPadding instantiations of that
mode. <br>
</p>
<p>Another way of looking at that - KW-AE can't use a variant ICV.
(Or at least I can't find a place where it's permitted - I was
mistaken in including it above as the same as RFC3394). If you're
going to call it KWP/NoPadding and KW/NoPadding, then maybe you
shouldn't support the provision of a different ICV as this isn't
supported by SP800-38F.</p>
<p>*shrug* <br>
</p>
<p>I don't think that Java nomenclature and NIST nomenclature have
to match up. But ideally, Java nomenclature should try to be
consistent amongst itself. AES/KWP/NoPadding just sounds less
right than AES/KW/KWPPadding.</p>
<p>Mike</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>