[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: use storage instead of DHT
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: use storage instead of DHT |
Date: |
Mon, 20 Dec 2021 01:59:03 +0100 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: use storage instead of DHT,
gnunet <=