[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: pass until records other
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: pass until records other |
|
Date: |
Mon, 20 Dec 2021 20:33:08 +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 bdfb89c pass until records other
bdfb89c is described below
commit bdfb89cba1d0cc93382e791a0867d345a91243ca
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 20:33:03 2021 +0100
pass until records other
---
draft-schanzen-gns.xml | 221 ++++++++++++++++++++++++-------------------------
1 file changed, 106 insertions(+), 115 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index e99e007..0b1e901 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -157,65 +157,64 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- A zone in GNS is defined by a zone type "ztype" that identifies
- a cryptosystem and a public/private key pair "(d,zk)",
- where "d" is the private key and "zk" the corresponding public key
- in the public key cipher identified by the "ztype".
+ A zone in GNS is defined by a zone type that identifies
+ a cryptosystem and a public/private key pair where d is the private
+ key and zk the corresponding public key.
The contents of a zone are cryptographically signed before
- being published.
- Records are grouped by their label, and encrypted (see <xref
target="zone_types"/>)
- using an encryption key derived from the label and the zone public key.
- Instead of the zone private key "d", the signature MUST
- be created using a blinded public/private key pair "d'" and "zk'".
+ being published by its owner for resolution by other parties.
+ Records are grouped by their label, and encrypted using an encryption
+ key derived from the label and the zone public key (see <xref
target="records_block"/>).
+ Instead of the zone private key d, the signature MUST
+ be created using a blinded public/private key pair.
This blinding is realized using a deterministic key
derivation scheme.
Such a scheme allows the deterministic derivation of keys from
- the original public and private zone keys using "label" values.
- Specifically, the zone owner can derive private keys "d'", and a
- resolver to derive the corresponding public keys "zk'". Using
- different "label" values in the derivation results in different
- keys. Without knowledge of the "label" values, the different
- derivations are unlinkable both to the original key and to each
+ the original public and private zone keys using record label values.
+ Specifically, the zone owner can derive private keys for each record
+ set published under a label, and a
+ resolver can derive the corresponding public keys.
+ Without knowledge of the label values and the zone public keys, the
+ different derivations are unlinkable both to the original key and to
each
other.
This prevents zone enumeration and requires knowledge
- of both "zk" and the "label" to confirm affiliation with a
- specific zone. At the same time, the blinded "zk'" provides nodes
+ of both the public zone key and the label to confirm affiliation with a
+ specific zone. At the same time, the blinded zone public key provides
nodes
with the ability to verifiy the integrity of the published information
without disclosing the originating zone.
</t>
<t>
- The following variables are associated with a zone in GNS:
+ Based on the above, the following variables are associated with a zone
in GNS:
</t>
<dl>
<dt>ztype</dt>
<dd>
- is the unique Zone Type of the zone as registered in the
+ is the unique zone type of the zone as registered in the
GNUnet Assigned Numbers Authority <xref target="GANA" />.
- The Zone Type determines which cryptosystem is used for the
+ The zone type determines which cryptosystem is used for the
asymmetric and symmetric key operations of the zone. A 32-bit number.
</dd>
<dt>d</dt>
<dd>
- is the private Zone Key. The specific format depends on the zone type.
+ is the private zone key. The specific format depends on the zone type.
</dd>
<dt>zk</dt>
<dd>
- is the public Zone Key. The specific format depends on the zone type.
+ is the public zone key. The specific format depends on the zone type.
</dd>
<dt>zid</dt>
<dd>
- is the Zone ID, a unique public identifier of a zone.
- It consists of the "ztype" and the public zone key "zk".
+ is the zone identifier, a unique public identifier of a zone.
+ It consists of the ztype and the public zone key zk.
</dd>
<dt>zkl</dt>
<dd>
- is the Zone Key Label. It is a string representation of the Zone ID.
+ is the zone key label. It is a string representation of the zone
identifier.
</dd>
<dt>zTLD</dt>
<dd>
- is the Zone Top-Level Domain. It is string which encodes the "zkl"
into
- a domain name.
- The "zTLD" is used as a globally unique reference to a specific
+ is the Zone Top-Level Domain. It is a string which encodes the zone
key
+ label into a domain name.
+ The zTLD is used as a globally unique reference to a specific
namespace in the process of name resolution.
</dd>
</dl>
@@ -235,16 +234,14 @@
]]></artwork>
</figure>
<t>
- The Zone Key Label is derived from the Zone ID using the Crockford
Base32
- encoding <xref target="CrockfordB32"/> but we decode the letter "U" to
+ The zone key label is derived from the zone identifier using the
Crockford Base32
+ encoding <xref target="CrockfordB32"/> but the letter "U" is decoded to
the same Base32 value as the letter "V" in order to further increase
tolerance for failures in character recognition.
The encoding and decoding symbols for Crockford Base32 including this
modification are defined in
<xref target="CrockfordB32Encode"/>.
- We assume that the functions for encoding and
- decoding based on this table are called
- "StringEncode(decodedString)" and
- "StringDecode(encodedString)".
+ The functions for encoding and decoding based on this table are called
+ GNSCrockfordEncode and GNSCrockfordDecode, respectively.
</t>
<figure anchor="CrockfordB32Encode">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -288,22 +285,23 @@ Value Symbol Symbol
The Base32-Crockford Alphabet Including the Additional U Encode Symbol.
</t>
<t>
- For the string representation of a Zone ID we define:
+ For the string representation of a zone identifier we define:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-zkl := StringEncode(zid)
-zid := StringDecode(zkl)
+zkl := GNSCrockfordEncode(zid)
+zid := GNSCrockfordDecode(zkl)
]]></artwork>
<t>
If zkl is less than 63 characters, it can directly be
- used as a Zone Top-Level Domain (zTLD).
- If the resulting Zone Key Label is be longer than 63 characters, the
+ used as a zTLD.
+ If zkl is be longer than 63 characters, the
zTLD is constructed by dividing zkl into smaller labels separated by the
label separator ".".
Here, the most significant bytes of the "zid" must be contained
in the rightmost label of the resulting string and the least significant
- bytes in the leftmost label of the resulting string. For example,
- assuming a zkl of 130 characters, the encoding would be:
+ bytes in the leftmost label of the resulting string. This allows the
+ resolver to determine the zone type and zkl length from the rightmost
label.
+ For example, assuming a zkl of 130 characters, the encoding would be:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
@@ -321,30 +319,30 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
<dl>
<dt>Private-KeyGen() -> d</dt>
<dd>
- is a function to generate a fresh private key "d".
+ is a function to generate a fresh private zone key d.
</dd>
<dt>Public-KeyGen(d) -> zk</dt>
<dd>
- is a function to derive a public key "zk" from a private key "d".
+ is a function to derive a public zone key zk from a private key d.
</dd>
<dt>ZKDF-Private(d,label) -> d'</dt>
<dd>
- is a zone key derivation function which blinds a private zone key "d"
- using "label", resulting in another private key which
+ is a zone key derivation function which blinds a private zone key d
+ using label, resulting in another private key which
can be used to create cryptographic signatures.
</dd>
<dt>ZKDF-Public(zk,label) -> zk'</dt>
<dd>
- is a zone key derivation function which blinds a public zone key "zk"
- using "label". "zk" and "zk'" must be unlinkable. Furthermore,
- blinding "zk" with different values for "label" must result
- in unlinkable different resulting values for "zk'".
+ is a zone key derivation function which blinds a public 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 different resulting values for zk'.
</dd>
<dt>S-Encrypt(zk,label,nonce,expiration,rdata) -> bdata</dt>
<dd>
is a deterministic symmetric encryption function which encrypts the
record
- data "rdata" based on key material derived from "zk", "label",
- "nonce" and "expiration".
+ data rdata based on key material derived from the public zone key,
+ a label, a nonce and an expiration.
In order to leverage performance-enhancing caching features of certain
underlying storages, in particular DHTs, a deterministic encryption
scheme is recommended.
@@ -352,22 +350,22 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
<dt>S-Decrypt(zk,label,nonce,expiration,bdata) -> rdata</dt>
<dd>
is a symmetric encryption function which decrypts the encrypted record
- data "bdata" based on key material derived from "zk", "label",
- "nonce" and "expiration".
+ data bdata based on key material derived from the public zone key,
+ a label, a nonce an expiration.
</dd>
<dt>Sign(d',bdata) -> sig</dt>
<dd>
- is a function to sign "bdata" using the (blinded) private key
- "d'", yielding an unforgable cryptographic signature "sig".
+ is a function to sign bdata using the (blinded) private key
+ d', yielding an unforgable cryptographic signature.
</dd>
<dt>Verify(zk',bdata,sig) -> valid</dt>
<dd>
- is a function to verify the signature "sig" was created by
- the a private key "d'" derived from "d" and "label" if
- "zk'" was derived from the corresponding to
- "zk := Public-Keygen(d)" and "label".
- The function returns "true" if the signature is valid,
- and otherwise "false".
+ is a function to verify the signature sig was created by
+ the a private key d' derived from d and a label if
+ zk' was derived from the corresponding zone key
+ zk := Public-Keygen(d) and same label.
+ The function returns a boolean value of "TRUE" if the signature is
valid,
+ and otherwise "FALSE".
</dd>
</dl>
</section>
@@ -377,12 +375,13 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
<t>
A GNS implementor MUST provide a mechanism to create and manage resource
records for local zones. A local zone is established by selecting a
- zone type and creating a zone
- key pair.
- Records may be added to each zone, hence a (local) persistency
- mechanism for resource records and zones must be provided.
- This local zone database is used by the GNS resolver implementation
- and to publish record information.
+ zone type and creating a zone key pair.
+ The creation of zone keys for the default zone types are specificed in
+ <xref target="gnsrecords_delegation"/>.
+ As records may be added to each created zone, a (local) persistency
+ mechanism such as a database for resource records and zones must be
provided.
+ This local zone database is used by the name resolution logic and serves
+ as a basis for publishing zones into the GNS storage (see <xref
target="publish"/>).
</t>
<t>
A GNS resource record holds the data of a specific record in a zone.
@@ -553,8 +552,6 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
defined in <xref target="RFC6979" /> as the curve point d*G where G
is the group generator of the elliptic curve.
This generation represents the Public-KeyGen(d) function.
- The public key is used to uniquely
- identify a GNS zone and is referred to as the "zone key".
</dd>
<dt>p</dt>
<dd>
@@ -572,8 +569,8 @@ zTLD := zkl[126:129].zkl[63:125].zkl[0:62]
</dd>
</dl>
<t>
- The "zid" of a PKEY is 32 + 4 bytes in length. This means that
- a "zTLD" will always fit into a single label and does
+ The zone identifier of a PKEY is 32 + 4 bytes in length. This means
that
+ a zTLD will always fit into a single label and does
not need any further conversion.
</t>
<t>
@@ -599,18 +596,16 @@ zk' := h mod L * zk
The PKEY cryptosystem uses a hash-based key derivation function
(HKDF) as defined in
<xref target="RFC5869" />, using HMAC-SHA512 for the extraction
phase and HMAC-SHA256 for the expansion phase.
- "PRK_h" is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "zk" as initial
+ PRK_h is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key as initial
keying material.
- "h" is the 512-bit HKDF expansion result and must be interpreted in
+ h is the 512-bit HKDF expansion result and must be interpreted in
network byte order. The expansion info input is
a concatenation of the label and string "gns".
- "label" is a UTF-8 string under which the resource records are
+ The label is a UTF-8 string under which the resource records are
published.
- </t>
- <t>
- We point out that the multiplication of "zk" with "h" is a point
multiplication,
- while the multiplication of "d" with "h" is a scalar multiplication.
+ The multiplication of zk with h is a point multiplication,
+ while the multiplication of d with h is a scalar multiplication.
</t>
<t>
The Sign() and Verify() functions
@@ -626,8 +621,8 @@ RDATA := CTR-AES256(K, IV, BDATA)
BDATA := CTR-AES256(K, IV, RDATA)
]]></artwork>
<t>
- The key "K" and counter "IV" are derived from
- the record "label" and the zone key "zk" as follows:
+ The key K and counter IV are derived from
+ the record label and the zone key zk as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -641,7 +636,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
extraction phase and HMAC-SHA256 for the expansion phase.
The output keying material is 32 bytes (256 bits) for the symmetric
key and 4 bytes (32 bits) for the nonce.
- The symmetric key "K" is a 256-bit AES <xref target="RFC3826" /> key.
+ The symmetric key K is a 256-bit AES <xref target="RFC3826" /> key.
</t>
<t>
The nonce is combined with a 64-bit initialization vector and a
@@ -651,7 +646,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The block counter is a 32-bit integer value in network byte order.
The initialization vector is the expiration time of the
resource record block in network byte order.
- The resulting counter ("IV") wire format can be found in
+ The resulting counter (IV) wire format can be found in
<xref target="figure_hkdf_ivs_pkey"/>.
</t>
<figure anchor="figure_hkdf_ivs_pkey">
@@ -720,19 +715,17 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
<dt>a</dt>
<dd>
- is is an integer derived from "d" using the SHA512 hash function
+ is is an integer derived from d using the SHA512 hash function
as defined in <xref target="ed25519" />.
</dd>
<dt>zk</dt>
<dd>
- is the EdDSA public zone key corresponding to "d". It is defined
in
- <xref target="ed25519" /> as the curve point "a*G" where "G" is
the
- group generator of the elliptic curve and "a" is an integer
- derived from "d" using the SHA512 hash function.
- This generation including the derivation of "a" represents the
+ is the EdDSA public zone key corresponding to d. It is defined in
+ <xref target="ed25519" /> as the curve point a*G where G is the
+ group generator of the elliptic curve and a is an integer
+ derived from d using the SHA512 hash function.
+ This generation including the derivation of a represents the
Public-KeyGen(d) function.
- The public key is used to uniquely identify a GNS zone and is
- referred to as the "zone key".
</dd>
<dt>p</dt>
<dd>
@@ -750,8 +743,8 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</dd>
</dl>
<t>
- The "zid" of an EDKEY is 32 + 4 bytes in length. This means that
- a "zTLD" will always fit into a single label and does
+ The zone identifier of an EDKEY is 32 + 4 bytes in length. This
means that
+ a zTLD will always fit into a single label and does
not need any further conversion.
</t>
<t>
@@ -781,7 +774,7 @@ zk' := h * zk
<t>
We note that implementors must employ a constant time scalar
multiplication for the constructions above. Also, implementors
- must ensure that the private key "a" is an ed25519 private key
+ must ensure that the private key a is an ed25519 private key
and specifically that "a[0] & 7 == 0" holds.
</t>
<t>
@@ -789,36 +782,34 @@ zk' := h * zk
hash-based key derivation function (HKDF) as defined in
<xref target="RFC5869" />, using HMAC-SHA512 for the extraction
phase and HMAC-SHA256 for the expansion phase.
- "PRK_h" is key material retrieved using an HKDF using the string
- "key-derivation" as salt and the public zone key "zk" as initial
+ PRK_h is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public zone key as initial
keying material.
- "h" is the 512-bit HKDF expansion result. The expansion info input
is
+ The blinding factor h is the 512-bit HKDF expansion result. The
expansion info input is
a concatenation of the label and string "gns".
The result of the HKDF must be clamped and interpreted in network
byte order.
- "a" is the 256-bit integer corresponding to the 256-bit private zone
- key "d".
- "label" is a UTF-8 string under which the resource records are
+ a is the 256-bit integer corresponding to the 256-bit private zone
+ key d.
+ The label is a UTF-8 string under which the resource records are
published.
- </t>
- <t>
- We point out that the multiplication of "zk" with "h" is a point
multiplication,
- while the division and multiplication of "a" and "a1" with the
+ The multiplication of zk with h is a point multiplication,
+ while the division and multiplication of a and a1 with the
cofactor are integer operations.
</t>
<t>
- Signatures for EDKEY zones using the derived private key "a'"
+ Signatures for EDKEY zones using the derived private key a'
are NOT compliant with <xref target="ed25519" />.
- As the corresponding private key to the derived private scalar "a'"
+ As the corresponding private key to the derived private scalar a'
is not known, it is not possible to deterministically derive the
- signature part "R" according to <xref target="ed25519" />.
+ signature part R according to <xref target="ed25519" />.
Instead, signatures MUST be generated as follows for any given
message M:
A nonce is calculated from the highest 32 bytes of the
- expansion of the private key "d" and the blinding factor "h".
- The "nonce" is then hashed with the message "M" to "r".
+ expansion of the private key d and the blinding factor h.
+ The nonce is then hashed with the message M to r.
This way, we include the full derivation path in the calculation
- the "R" value of the signature, ensuring that it is never resused
+ of the R value of the signature, ensuring that it is never reused
for two different derivation paths or messages.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -846,13 +837,13 @@ BDATA := XSalsa20(K, IV, RDATA) = CIPHERTEXT | TAG
<t>
The result of the XSalsa20 encryption function is the encrypted
ciphertext concatenated with the 128-bit authentication
- tag "TAG".
+ tag TAG.
Accordingly, the length of BDATA equals the length of the
RDATA plus the 16 bytes of the authentication tag.
</t>
<t>
- The key "K" and counter "IV" are derived from
- the record "label" and the zone key "zk" as follows:
+ The key K and counter IV are derived from
+ the record label and the zone key zk as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -866,7 +857,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
extraction phase and HMAC-SHA256 for the expansion phase.
The output keying material is 32 bytes (256 bits) for the symmetric
key and 16 bytes (128 bits) for the NONCE.
- The symmetric key "K" is a 256-bit XSalsa20
+ The symmetric key K is a 256-bit XSalsa20
<xref target="XSalsa20" /> key.
No additional authenticated data (AAD) is used.
</t>
@@ -874,7 +865,7 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
The nonce is combined with an 8 byte initialization vector.
The initialization vector is the expiration time of the
resource record block in network byte order.
- The resulting counter ("IV") wire format is illustrated in
+ The resulting counter (IV) wire format is illustrated in
<xref target="figure_hkdf_ivs_edkey"/>.
</t>
<figure anchor="figure_hkdf_ivs_edkey">
--
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: pass until records other,
gnunet <=