<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Initialization vector for AES-GCM in Intel® Software Guard Extensions (Intel® SGX)</title>
    <link>https://community.intel.com/t5/Intel-Software-Guard-Extensions/Initialization-vector-for-AES-GCM/m-p/1067776#M194</link>
    <description>&lt;P&gt;The official GCM specification at&amp;nbsp;http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf states that the initialization vector should be unique for every GCM encryption operation using one key. However, the Remote Attestation SDK sample uses a zero IV for GCM encryption.&lt;/P&gt;

&lt;P&gt;Moreover, the SDK function &lt;SPAN style="color: rgb(121, 93, 163); font-family: Consolas, &amp;quot;Liberation Mono&amp;quot;, Menlo, Courier, monospace; font-size: 12px; white-space: pre;"&gt;sgx_seal_data_ex&lt;/SPAN&gt; also uses a zero IV:&lt;/P&gt;

&lt;P&gt;&lt;A href="https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L72" target="_blank"&gt;https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L72&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;...the IV is then passed unchanged to&amp;nbsp;&lt;SPAN style="color: rgb(0, 134, 179); font-family: Consolas, &amp;quot;Liberation Mono&amp;quot;, Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(248, 238, 199);"&gt;sgx_seal_data_iv:&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&lt;A href="https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L147" target="_blank"&gt;https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L147&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;Is there something I'm not getting here (I'm not a cryptography expert after all)?&lt;/P&gt;</description>
    <pubDate>Thu, 12 Jan 2017 10:44:28 GMT</pubDate>
    <dc:creator>Rafal_W_</dc:creator>
    <dc:date>2017-01-12T10:44:28Z</dc:date>
    <item>
      <title>Initialization vector for AES-GCM</title>
      <link>https://community.intel.com/t5/Intel-Software-Guard-Extensions/Initialization-vector-for-AES-GCM/m-p/1067776#M194</link>
      <description>&lt;P&gt;The official GCM specification at&amp;nbsp;http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf states that the initialization vector should be unique for every GCM encryption operation using one key. However, the Remote Attestation SDK sample uses a zero IV for GCM encryption.&lt;/P&gt;

&lt;P&gt;Moreover, the SDK function &lt;SPAN style="color: rgb(121, 93, 163); font-family: Consolas, &amp;quot;Liberation Mono&amp;quot;, Menlo, Courier, monospace; font-size: 12px; white-space: pre;"&gt;sgx_seal_data_ex&lt;/SPAN&gt; also uses a zero IV:&lt;/P&gt;

&lt;P&gt;&lt;A href="https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L72" target="_blank"&gt;https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L72&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;...the IV is then passed unchanged to&amp;nbsp;&lt;SPAN style="color: rgb(0, 134, 179); font-family: Consolas, &amp;quot;Liberation Mono&amp;quot;, Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(248, 238, 199);"&gt;sgx_seal_data_iv:&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&lt;A href="https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L147" target="_blank"&gt;https://github.com/01org/linux-sgx/blob/master/sdk/tseal/tSeal.cpp#L147&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;Is there something I'm not getting here (I'm not a cryptography expert after all)?&lt;/P&gt;</description>
      <pubDate>Thu, 12 Jan 2017 10:44:28 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Software-Guard-Extensions/Initialization-vector-for-AES-GCM/m-p/1067776#M194</guid>
      <dc:creator>Rafal_W_</dc:creator>
      <dc:date>2017-01-12T10:44:28Z</dc:date>
    </item>
    <item>
      <title>TL;DR: The encryption sealing</title>
      <link>https://community.intel.com/t5/Intel-Software-Guard-Extensions/Initialization-vector-for-AES-GCM/m-p/1067777#M195</link>
      <description>&lt;P&gt;TL;DR: The encryption sealing key is always different, therefore it is OK to use the same IV.&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&lt;U&gt;More details:&lt;/U&gt;&lt;/P&gt;

&lt;P&gt;Notice that in sgx_seal_data_ex there is a variable called keyID. This variable is filled with random values using a call to sgx_read_rand which is a wrapper to the RDRAND instruction (using true entropy source, see chapter 7.3.17.1 &amp;nbsp;in the SDM, volume 1). &lt;SPAN style="font-size: 13.008px;"&gt;keyID&lt;/SPAN&gt; is copied to a field in tmp_key_request, which is passed on to the function sgx_seal_data_iv, implemented in tSeal_internal.cpp. &amp;nbsp;&lt;SPAN style="font-size: 13.008px;"&gt;sgx_seal_data_iv calls sgx_get_key which is a wrapper to the EGETKEY instruction. The keyID is used by EGETKEY to ensure a fresh encryption sealing key is generated.&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&lt;SPAN style="font-size: 13.008px;"&gt;&lt;U&gt;&lt;EM&gt;Conclusion&lt;/EM&gt;&lt;/U&gt;: a different sealing key is used every time, therefore it is safe to use a constant IV in the AES-GCM.&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&lt;SPAN style="font-size: 13.008px;"&gt;&lt;EM&gt;&lt;U&gt;Why is that so?&lt;/U&gt;&lt;/EM&gt; The NIST document specification of AES-GCM sets a maximum limit on number of invocation of AES_GCM with IV length of 96 bits. The limit is 2^32. To avoid a limit on the number of invocation of the sealing key, you can generate a new key every time.&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;(If anyone has a different interpretation, I'd be happy to stand corrected)&lt;/P&gt;

&lt;P&gt;Ofir&lt;/P&gt;</description>
      <pubDate>Fri, 13 Jan 2017 01:02:15 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Software-Guard-Extensions/Initialization-vector-for-AES-GCM/m-p/1067777#M195</guid>
      <dc:creator>Ofir_W_</dc:creator>
      <dc:date>2017-01-13T01:02:15Z</dc:date>
    </item>
  </channel>
</rss>

