<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 4/11/2018 5:37 AM, Bernd Eckenfels wrote:<br>
</p>
<blockquote type="cite"
cite="mid:AM4PR08MB1219EF8C5DF5DB65645D9A5CFFBD0@AM4PR08MB1219.eurprd08.prod.outlook.com"><!-- This file has been automatically generated. See web/README.md -->
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div id="compose-container" style="direction: ltr" itemscope=""
itemtype="https://schema.org/EmailMessage">
<span itemprop="creator" itemscope=""
itemtype="https://schema.org/Organization"><span
itemprop="name" content="Outlook Mobile for iOS"></span></span>
<div>
<div style="direction: ltr;">Hello,</div>
<div><br>
</div>
<div style="direction: ltr;">I noticed that the OASIS draft
for extending PKCS#11 with SHA-3 also specifies new
Mechanisms for SHAKE128/256. They introduce them as Key
Derivation functions.</div>
</div>
</div>
</blockquote>
<br>
Interesting. Though to be pedantic, it looks like they introduce key
derivation mechanisms that are based on SHAKE128/256.<br>
<br>
<blockquote type="cite"
cite="mid:AM4PR08MB1219EF8C5DF5DB65645D9A5CFFBD0@AM4PR08MB1219.eurprd08.prod.outlook.com">
<div id="compose-container" style="direction: ltr" itemscope=""
itemtype="https://schema.org/EmailMessage">
<div>
<div><br>
</div>
<div style="direction: ltr;">I wonder if this would also be
the way to introduce this into JCA, at the moment XOFs have
been a non-goal of JEP287, but there is some use for them In
modern protocols I would guess. (This request was inspired
by a discussion on the bouncycastle crypto-dev mailing list
about missing algorithms for it).</div>
</div>
</div>
</blockquote>
<br>
Continuing the pedantry, it would be reasonable to put these
SHAKE128/256-based-KDFs under the KDF API (once that API exists).
But the underlying SHAKE XOFs probably belong in a different API
like MessageDigest or a new API that is more appropriate for XOFs. I
expect that adding the XOFs to the API will be non-trivial because
we don't have an obviously good place to put them. I think it would
be fine to put them in MessageDigest, but we would need a way to
specify the output length. <br>
<br>
We will need SHAKE256 for Ed448[1], but my initial thought was to do
a private implementation, because I don't know if these functions
are useful enough to justify the effort of the API design. Maybe we
can make an API for them as a separate effort. <br>
<br>
It's also worth noting that the (bare) XOFs are not very good KDFs
because they allow key extraction through related output attacks. <br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8187789">https://bugs.openjdk.java.net/browse/JDK-8187789</a><br>
</body>
</html>