[lsd0001] branch master updated: use storage instead of DHT

[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 8417395  use storage instead of DHT
8417395 is described below

commit 841739521c57e7259b0913586ff146424aafdc9a
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 01:58:56 2021 +0100

    use storage instead of DHT
---
 draft-schanzen-gns.xml | 58 ++++++++++++++++++++++++++------------------------
 1 file changed, 30 insertions(+), 28 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index dd76c25..d7cc681 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -138,9 +138,9 @@
        This document defines the normative wire format of resource records, 
resolution processes,
        cryptographic routines and security considerations for use by 
implementors.
        In general any API which allows storing a value under a key and 
retrieving
-       a value from the key can be used by an implementation for record 
storage.
-       It is expected that a GNS implementation is using a distributed hash
-       table (DHT).
+     a value from the key can be used by an implementation for record storage.
+     It is expected that a GNS implementation is using a distributed hash
+     table (DHT).
        Specification of such a DHT is out of scope of this document but
        possible existing implementations include <xref target="RFC7363" />
        <xref target="Kademlia" />, <xref target="R5N" /> or <xref 
target="Ipfs" />.
@@ -169,7 +169,7 @@
        where "d" is the private key and "zk" the corresponding public key
        in the public key cipher identified by the "ztype".
        The contents of a zone are cryptographically signed before
-       being published in a distributed hash table (DHT).
+       being published.
        Records are grouped by their label, and encrypted (<xref 
target="recordencryption"/>)
        using an encryption key derived from the label and the zone public key.
        Instead of the zone private key "d", the signature MUST
@@ -342,7 +342,7 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          "nonce" and "expiration".
          A deterministic encryption scheme is
          required to improve performance by leveraging caching features
-         of DHTs.
+         of underlying storages, in particular DHTs.
        </dd>
        <dt>Sign(d',bdata) -> sig</dt>
        <dd>
@@ -464,14 +464,15 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          If this flag is set, this record should be ignored by resolvers 
unless all (other)
          records of the same record type have expired.  Used to allow zone 
publishers to
          facilitate good performance when records change by allowing them to 
put future
-         values of records into the DHT. This way, future values can propagate 
and may be
+         values of records into the storage.
+         This way, future values can propagate and may be
          cached before the transition becomes active.
        </dd>
        <dt>EXPREL</dt>
        <dd>
          The expiration time value of the record is a relative time (still in 
microseconds)
          and not an absolute time. This flag should never be encountered by a 
resolver
-         for records obtained from the DHT, but might be present when a 
resolver looks up
+         for records obtained from the storage, but might be present when a 
resolver looks up
          private records of a zone hosted locally.
        </dd>
        <dt>
@@ -482,13 +483,13 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
          other records. This flag indicates that this record is not explicitly
          managed alongside the other records under the respective name but
          may be useful for the application. This flag should only be 
encountered
-         by a resolver for records obtained from the DHT.
+         by a resolver for records obtained from the storage.
        </dd>
        <dt>PRIVATE</dt>
        <dd>
          This is a private record of this peer and it should thus not be
-         published in the DHT.  Thus, this flag should never be encountered by
-         a resolver for records obtained from the DHT.
+         published.  Thus, this flag should never be encountered by
+         a resolver for records obtained from the storage.
          Private records should still be considered just like
          regular records when resolving labels in local zones.
        </dd>
@@ -1118,14 +1119,14 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
        We assume that a storage API provides two functions: GET(key) and 
PUT(key,value).
        In GNS, resource records are grouped by their respective labels,
        encrypted and published together in a single resource records block
-       (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
+       (RRBLOCK) in the storage under a key "q": PUT(q, RRBLOCK).
        The key "q" which is derived from the zone key "zk" and the respective
        "label" of the contained records.
      </t>
      <section anchor="blinding" numbered="true" toc="default">
-       <name>DHT Key Derivations</name>
+       <name>Storage Key Derivations</name>
        <t>
-         Given a label, the DHT key "q" is derived as follows:
+         Given a label, the storage key "q" is derived as follows:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 q := SHA512 (HDKD-Public(zk, label))
@@ -1140,7 +1141,7 @@ q := SHA512 (HDKD-Public(zk, label))
          </dd>
          <dt>q</dt>
          <dd>
-           Is the 512-bit DHT key under which the resource records block is
+           Is the 512-bit storage key under which the resource records block is
            published.
            It is the SHA512 hash over the derived public zone key.
          </dd>
@@ -1150,14 +1151,14 @@ q := SHA512 (HDKD-Public(zk, label))
        <name>Resource Records Block</name>
        <t>
          GNS records are grouped by their labels and published as a single
-         block in the DHT. The grouped record sets MAY be paired with any
+         block in the storage. The grouped record sets MAY be paired with any
          number of supplemental records. Supplemental records must have the
          supplemental flag set (See <xref target="rrecords"/>).
          The contained resource records are encrypted using a symmetric
          encryption scheme.
          A GNS implementation must publish RRBLOCKs
          in accordance to the properties and recommendations of the underlying
-         DHT. This may include a periodic refresh publication.
+         storage. This may include a periodic refresh publication.
          The GNS RRBLOCK wire format is illustrated in 
          <xref target="figure_record_block"/>.
        </t>
@@ -1225,7 +1226,7 @@ q := SHA512 (HDKD-Public(zk, label))
          <dt>EXPIRATION</dt>
          <dd>
            Specifies when the RRBLOCK expires and the encrypted block
-           SHOULD be removed from the DHT and caches as it is likely stale.
+           SHOULD be removed from the storage and caches as it is likely stale.
            However, applications MAY continue to use non-expired individual
            records until they expire.  The value MUST be set to the
            expiration time of the resource record contained within this block 
with the
@@ -1320,7 +1321,7 @@ q := SHA512 (HDKD-Public(zk, label))
    <section anchor="resolution" numbered="true" toc="default">
      <name>Name Resolution</name>
      <t>
-       Names in GNS are resolved by recursively querying the DHT record 
storage.
+       Names in GNS are resolved by recursively querying the record storage.
        In the following, we define how resolution is initiated and each
        iteration in the resolution is processed.
      </t>
@@ -1356,17 +1357,17 @@ q := SHA512 (HDKD-Public(zk, label))
            <li>Extract the right-most label from the name to look up.</li>
            <li>Calculate q using the label and zk as defined in
            <xref target="blinding" />.</li>
-           <li>Perform a DHT query GET(q) to retrieve the RRBLOCK.</li>
+           <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
            <li>Verify and process the RRBLOCK and decrypt the BDATA contained
              in it as defined in <xref target="recordencryption" />.</li>
          </ol>
          <t>
-           Upon receiving the RRBLOCK from the DHT, apart from verifying the
+           Upon receiving the RRBLOCK from the storage, apart from verifying 
the
            provided signature, the resolver MUST check that the authoritative
            zone key was used to sign the record:
            The derived zone key "h*zk" MUST match the public key provided in
-           the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT 
lookup
-           GET(q) MUST continue.
+           the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the storage
+           lookup GET(q) MUST continue.
          </t>
        </section>
        <section anchor="record_processing" numbered="true" toc="default">
@@ -1969,7 +1970,7 @@ example.com = zk2
            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
+           ensured that each time a block is published into the storage, its 
IV is
            unique as the expiration time is calculated dynamically and 
increases
            monotonically.
            For blocks with absolute expiration times, the implementation
@@ -2024,12 +2025,12 @@ example.com = zk2
          </t>
        </section>
        <section anchor="security_dht" numbered="true" toc="default">
-         <name>Impact of underlying DHTs</name>
+         <name>Impact of DHTs as Underlying Storage</name>
          <t>
            This document does not specifiy the properties of the underlying
-           distributed hash table (DHT) which is required by any GNS
-           implementation. For implementors, it is important to note that
-           the properties of the DHT are directly inherited by the
+           storage which is required by any GNS implementation.
+           For implementors using a DHT as underlying storage, it is important
+           to note that the properties of the DHT are directly inherited by the
            GNS implementation. This includes both security as well as
            other non-functional properties such as scalability and performance.
            Implementors should take great care when selecting or implementing
@@ -2165,7 +2166,8 @@ Purpose | Name            | References | Description
          <xref target="GNUnetGNS"/> represents the original
          and reference implementation. The Go implementation
          <xref target="GoGNS"/> demonstrates how two implementations of GNS are
-         interoperable given that they are built on top of the same DHT.
+         interoperable given that they are built on top of the same underlying
+         DHT storage.
        </t>
        <t>
          Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/>

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