[lsd0001] branch master updated: update symmetric encryption for IND-CCA

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 45520f9  update symmetric encryption for IND-CCA
45520f9 is described below

commit 45520f94f5e379d54519b37cb1fd3f7835ceafe3
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
AuthorDate: Sat Sep 19 13:24:05 2020 +0200

    update symmetric encryption for IND-CCA
---
 draft-schanzen-gns.xml | 82 +++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 61 insertions(+), 21 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 4b6cab3..8db1fd9 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -5,6 +5,7 @@
 <!ENTITY RFC2119 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";>
 <!ENTITY RFC2782 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml";>
 <!ENTITY RFC3629 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml";>
+<!ENTITY RFC3686 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml";>
 <!ENTITY RFC3826 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml";>
 <!ENTITY RFC3912 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml";>
 <!ENTITY RFC5869 PUBLIC '' 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml";>
@@ -903,6 +904,9 @@ q := SHA512 (HDKD-Public(zk, label))
 
        </dl>
        <t>
+         DHTs often offer caching in oder to improve performance.
+         In order to leverage this, a deterministic encryption scheme is
+         required in order to leverage caching features.
          The symmetric keys and initialization vectors are derived from the
          record label and the zone key "zk". For decryption of the resource
          records block payload, the key material "K" and initialization vector
@@ -912,15 +916,16 @@ q := SHA512 (HDKD-Public(zk, label))
 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
 PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
 K := HKDF-Expand (PRK_k, label, 512 / 8);
-IV := HKDF-Expand (PRK_iv, label, 256 / 8)
-         ]]></artwork>
+NONCES := HKDF-Expand (PRK_iv, label, 32 / 8)
+IV := EXPIRATION
+]]></artwork>
        <t>
          HKDF is a hash-based key derivation function as defined in
          <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
          extraction phase and HMAC-SHA256 for the expansion phase.
          The output keying material is 64 octets (512 bit) for the symmetric
-         keys and 32 octets (256 bit) for the initialization vectors.
-         We divide the resulting keying material "K" into a 256-bit AES
+         keys and 16 octets (128 bit) for the nonces.
+         We divide the resulting keying material "K" into a 256 bit AES
          <xref target="RFC3826" /> key
          and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
        </t>
@@ -942,34 +947,52 @@ IV := HKDF-Expand (PRK_iv, label, 256 / 8)
          <!--        <postamble>which is a very simple example.</postamble>-->
        </figure>
        <t>
-         Similarly, we divide "IV" into a 128-bit initialization vector
-         and a 128-bit initialization vector:
+         The NONCES are divided into two 32 bit NONCE values. Each is combined
+         with a 64 bit  initialization vecor and a counter as defined in
+         <xref target="RFC3686" /> into a 128 bit COUNTERBLOCK.
+         The initialization vector is the expiration time of the resource
+         record block:
        </t>
        <figure anchor="figure_hkdf_ivs">
          <artwork name="" type="" align="left" alt=""><![CDATA[
-0     8     16    24    32    40    48    56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                    AES IV                     |
-|                                               |
-+-----+-----+-----+-----+-----+-----+-----+-----+
-|                  TWOFISH IV                   |
-|                                               |
-+-----+-----+-----+-----+-----+-----+-----+-----+
+0     8     16    24    32
++-----+-----+-----+-----+
+|         NONCE         |
++-----+-----+-----+-----+
+|       EXPIRATION      |
+|                       |
++-----+-----+-----+-----+
+|        COUNTER        |
++-----+-----+-----+-----+
            ]]></artwork>
          <!--        <postamble>which is a very simple example.</postamble>-->
        </figure>
 
        <t>
-         The keys and IVs are used for a CFB128-AES-256 and
-         CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
-         Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
+         The keys and counter blocks are used for a CTR-AES-256 and
+         CTR-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
+         counter mode (CTR) as defined in <xref target="MODES" />.
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
-RDATA := AES(K[0:31], IV[0:15],
-             TWOFISH(K[32:63], IV[16:31], BDATA))
-BDATA := TWOFISH(K[32:63], IV[16:31],
-                 AES(K[0:31], IV[0:15], RDATA))
+RDATA := AES(K[0:31], COUNTERBLOCK,
+             TWOFISH(K[32:63], COUNTERBLOCK, BDATA))
+BDATA := TWOFISH(K[32:63], COUNTERBLOCK,
+                 AES(K[0:31], COUNTERBLOCK, RDATA))
          ]]></artwork>
+       <t>
+         In order to ensure ciphertext indistinguishability, care must be
+         taken with respect to the initialization vector in the counter
+         block. In our design, the IV is always the expiration time of the
+         record block.
+         For blocks with relative expiration times it is implicitly
+         ensured that each time a block is published into the DHT, its IV is
+         unique as the expiration time is calculated dynamically and increases
+         monotonically.
+         For blocks with absolute expiration times, the implementation
+         MUST ensure that the expiration time is modified when the record
+         data changes. For example. the expiration time may be increased
+         by a single microsecond.
+       </t>
      </section>
    </section>
    <section anchor="encoding" numbered="true" toc="default">
@@ -1950,6 +1973,7 @@ ee83f0cc79c4c5ea
        &RFC2782;
        &RFC2119;
        &RFC3629;
+       &RFC3686;
        &RFC3826;
        &RFC3912;
        &RFC5869;
@@ -2039,6 +2063,22 @@ ee83f0cc79c4c5ea
            </abstract>
          </front>
        </reference>
+       <reference anchor="MODES" 
target="https://doi.org/10.6028/NIST.SP.800-38A";>
+         <front>
+           <title>Recommendation for Block Cipher Modes of Operation: Methods 
and Techniques</title>
+          <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
+            <organization>NIST</organization>
+          </author>
+
+           <date year="2001" month="December"/>
+           <abstract>
+             <t>
+               This recommendation defines five confidentiality modes of 
operation for use with an underlying symmetric key block cipher algorithm: 
Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), 
Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher 
algorithm that is approved in a Federal Information Processing Standard (FIPS), 
these modes can provide cryptographic protection for sensitive, but 
unclassified, computer data.
+             </t>
+           </abstract>
+         </front>
+       </reference>
+
        <!--    <reference anchor="ISO20022">
          <front>
          <title>ISO 20022 Financial Services - Universal financial industry 
message scheme</title>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.