<p dir="auto">see <a href="https://github.com/denoland/deno/blob/v1.13.0/extensions/crypto/00_crypto.js#L441-L540">importKey</a>, in its <code class="notranslate">constructKey</code> HMAC call the value <code class="notranslate">extractable</code> argument is hardcoded to <code class="notranslate">true</code>, disregarding the value of the argument passed in.</p>
<p dir="auto"><a href="https://github.com/denoland/deno/blob/v1.13.0/extensions/crypto/00_crypto.js#L519-L525">https://github.com/denoland/deno/blob/v1.13.0/extensions/crypto/00_crypto.js#L519-L525</a></p>
<p dir="auto">refs <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="949719061" data-permission-text="Title is private" data-url="https://github.com/denoland/deno/issues/11481" data-hovercard-type="issue" data-hovercard-url="/denoland/deno/issues/11481/hovercard" href="https://github.com/denoland/deno/issues/11481">#11481</a></p>
<p dir="auto">Before some we can do this we need confirmation from spec authors for the following statements:</p>
<ol dir="auto">
<li>Non extractable keys are not meant to be a security primitive. They are purely meant for obfuscation.</li>
<li>It is expected that a compromise of the render process, or in process timing side channel attacks (Spectre) can extract "non extractable" keys.</li>
</ol>
<p dir="auto">If either of these statements are not correct we do not have any technical way to implement non extractable keys securely.</p>
<p dir="auto">Knowing more about how web crypto is implemented in browsers (Chrome, Safari, and Firefox) would help here:</p>
<ul dir="auto">
<li>Is underlying key material stored in the render process, or in a separate process that communicates with the render process via IPC for any cryptographic operations?</li>
</ul>