[lsd0001] branch master updated: draft senc

[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 6a39c87  draft senc
6a39c87 is described below

commit 6a39c87f29c77328cf016908a290d9ea379ae4af
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Feb 4 16:44:19 2022 +0100

    draft senc
---
 draft-schanzen-gns.xml | 37 ++++++++++++++++++++++++++++---------
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index dfdde70..26d0d70 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -87,6 +87,7 @@
       GNS is a decentralized and censorship-resistant name
       system that provides a privacy-enhancing alternative to the Domain
       Name System (DNS).
+      <!-- GNS is more. it is also extensible and more flexible -->
     </t>
     <t>
       This document defines the normative wire format of resource records,
@@ -118,7 +119,7 @@
        and integrity of information on the Internet.
      </t>
      <t>
-       DNS was not designed with security as a goal. This makes it very
+       DNS was not designed with security in mind. This makes it very
        vulnerable, especially to attackers that have the technical capabilities
        of an entire nation state at their disposal.
        While a wider discussion of this issue is out of scope for this 
document,
@@ -228,7 +229,12 @@
        <dt>Blinded Zone Key</dt>
        <dd>
          A blinded zone key is derived from the zone key and a label.
-         The zone key and the blinded zone key are unlinkable without knowing 
the label.
+         The zone key and the blinded zone key are unlinkable without 
knowledge of the label.
+       </dd>
+       <dt>Zone Key Derivation Function</dt>
+       <dd>
+         The zone key derivation function (ZKDF) blinds a key using a label.
+         There are different functions for public and private keys, 
respectively.
        </dd>
        <dt>Zone Owner</dt>
        <dd>
@@ -352,7 +358,7 @@
      <dl>
        <dt>KeyGen() -> d, zk</dt>
        <dd>
-         is a function to generate a fresh private key d and
+         is a function to generate a new private key d and
         the corresponding public zone key zk.
        </dd>
        <dt>ZKDF-Private(d,label) -> d'</dt>
@@ -368,22 +374,22 @@
          is a zone key derivation function which blinds a zone key zk
          using a label. zk and zk' must be unlinkable. Furthermore,
          blinding zk with different values for the label must result
-         in unlinkable zk' values.
+         in different, unlinkable zk' values.
        </dd>
-       <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
+       <dt>S-Encrypt(zk,label,expiration,message) -> ciphertext</dt>
        <dd>
          is a symmetric encryption function which encrypts the record
          data based on key material derived from the zone key,
-         a label, a nonce and an expiration.
+         a label, and an expiration timestamp.
          In order to leverage performance-enhancing caching features of certain
          underlying storages, in particular DHTs, a deterministic encryption
          scheme is recommended.
        </dd>
-       <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt>
+       <dt>S-Decrypt(zk,label,expiration,ciphertext) -> message</dt>
        <dd>
          is a symmetric decryption function which decrypts the encrypted record
          data based on key material derived from the zone key,
-         a label, a nonce and an expiration.
+         a label, and an expiration timestamp.
        </dd>
        <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
        <dd>
@@ -508,7 +514,7 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
          published.
          This message MUST be signed using the private key.
          The revocation message is broadcast to the network.
-         The specification of the broadcast mechanism is out of scope of this
+         The specification of the broadcast mechanism is out of scope for this
          document.
          A possible broadcast mechanism for efficient flooding in a distributed
          network is implemented in <xref target="GNUnet"/>.
@@ -1047,6 +1053,19 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
            ]]></artwork>
        </figure>
        <t>The Block Counter Wire Format.</t>
+       <figure anchor="figure_senc_pkey">
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+S-Encrypt(zk,label,expiration,message):
+  PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+  PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
+  K := HKDF-Expand (PRK_k, label, 256 / 8);
+  NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
+  IV := NONCE | expiration | 0x0000000000000001
+  CIPHERTEXT := CTR-AES256(K, IV, DATA)
+  DATA := CTR-AES256(K, IV, CIPHERTEXT)
+           ]]></artwork>
+       </figure>
+       <t>The PKEY S-Encrypt Procedure.</t>
      </section>
      <section anchor="gnsrecords_edkey" numbered="true" toc="default">
        <name>EDKEY</name>

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