gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [lsd0001] branch master updated: update crypto intro


From: gnunet
Subject: [GNUnet-SVN] [lsd0001] branch master updated: update crypto intro
Date: Fri, 04 Oct 2019 15:32:27 +0200

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 487bdc9  update crypto intro
487bdc9 is described below

commit 487bdc9926cca878d39adcb503ff30f99bc811bc
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Fri Oct 4 15:30:17 2019 +0200

    update crypto intro
---
 draft-schanzen-gns.html |  38 ++++-
 draft-schanzen-gns.txt  | 438 ++++++++++++++++++++++++------------------------
 draft-schanzen-gns.xml  |  41 ++++-
 3 files changed, 283 insertions(+), 234 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 51c01b4..01f296a 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1157,15 +1157,39 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
       </h2>
 <p id="section-2-1">
     A zone in GNS is defined by a public/private ECC key pair (d,zk),
-    where d is the private key and
-    zk the corresponding public key.
-    GNS uses the Ed25519 EC parameters as defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>.
-    GNS combines the EC parameters of Ed25519 with the ECDSA scheme
-    defined in <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> in 
order to achieve zone privacy.
+    where d is the private key and zk the corresponding public key.
+    GNS combines the EC parameters of Ed25519 (<span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>)
+    with the ECDSA scheme (<span>[<a href="#RFC6979" 
class="xref">RFC6979</a>]</span>).
+    The deterministic property of ECDSA (as opposed to EdDSA) is required
+    in order to achieve zone privacy.
+    Records published in a zone are signed using a derived private key
+    as described in <a href="#publish" class="xref">Section 4</a>.
     The public key "zk" is used to uniquely identify and refer to the zone and
     is thus called "zone key".
-    Records published in the zone are signed using a private key derived
-    from "d" as described in <a href="#publish" class="xref">Section 4</a>.<a 
href="#section-2-1" class="pilcrow">¶</a></p>
+    In the following, we use the following naming convention for out
+    cryptographic primitives:<a href="#section-2-1" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-2-2">
+        <dt id="section-2-2.1">d</dt>
+        <dd id="section-2-2.2">
+      is a private key. It is defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span> as a b-bit
+      string. In our case, b is 256.<a href="#section-2-2.2" 
class="pilcrow">¶</a>
+</dd>
+        <dt id="section-2-2.3">p</dt>
+        <dd id="section-2-2.4">
+      is the prime of edwards25519 as defined in <span>[<a href="#RFC8032" 
class="xref">RFC8032</a>]</span>.<a href="#section-2-2.4" class="pilcrow">¶</a>
+</dd>
+        <dt id="section-2-2.5">B</dt>
+        <dd id="section-2-2.6">
+      is the group generator of the elliptic curve as defined in
+      <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span> for EdDSA.<a 
href="#section-2-2.6" class="pilcrow">¶</a>
+</dd>
+        <dt id="section-2-2.7">zk</dt>
+        <dd id="section-2-2.8">
+      is the ECDSA public key corresponding to d. It is defined in
+      <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the curve 
point d*B where B is the group
+      generator of the elliptic curve.<a href="#section-2-2.8" 
class="pilcrow">¶</a>
+</dd>
+      </dl>
 </section>
 </div>
 <div id="rrecords">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index c976501..1e43850 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -3,9 +3,11 @@
 
 
 Independent Stream                                       M. Schanzenbach
-Internet-Draft                                              C. Grothhoff
-Intended status: Informational                                    B. Fix
-Expires: 24 January 2020                                     GNUnet e.V.
+Internet-Draft                                               GNUnet e.V.
+Intended status: Informational                              C. Grothhoff
+Expires: 24 January 2020                           Berner Fachhochschule
+                                                                  B. Fix
+                                                             GNUnet e.V.
                                                             23 July 2019
 
 
@@ -51,8 +53,6 @@ Copyright Notice
 
 
 
-
-
 Schanzenbach, et al.     Expires 24 January 2020                [Page 1]
 
 Internet-Draft             The GNU Name System                 July 2019
@@ -62,14 +62,14 @@ Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
-   3.  Resource records  . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  Resource records  . . . . . . . . . . . . . . . . . . . . . .   3
      3.1.  PKEY  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
-     3.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     3.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . .   5
      3.3.  LEHO  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
-     3.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
-   4.  Publishing records  . . . . . . . . . . . . . . . . . . . . .   6
-     4.1.  Key derivations . . . . . . . . . . . . . . . . . . . . .   6
-     4.2.  Resource records block  . . . . . . . . . . . . . . . . .   7
+     3.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Publishing records  . . . . . . . . . . . . . . . . . . . . .   7
+     4.1.  Key derivations . . . . . . . . . . . . . . . . . . . . .   7
+     4.2.  Resource records block  . . . . . . . . . . . . . . . . .   8
      4.3.  Block data encryption and decryption  . . . . . . . . . .   9
    5.  Internationalization and Character Encoding . . . . . . . . .  11
    6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
@@ -95,17 +95,17 @@ Table of Contents
 
    A zone in GNS is defined by a public/private ECC key pair (d,zk),
    where d is the private key and zk the corresponding public key.  GNS
-   uses the Ed25519 EC parameters as defined in [RFC8032].  GNS combines
-   the EC parameters of Ed25519 with the ECDSA scheme defined in
-   [RFC6979] in order to achieve zone privacy.  The public key "zk" is
-   used to uniquely identify and refer to the zone and is thus called
-   "zone key".  Records published in the zone are signed using a private
-   key derived from "d" as described in Section 4.
-
-3.  Resource records
+   combines the EC parameters of Ed25519 ([RFC8032]) with the ECDSA
+   scheme ([RFC6979]).  The deterministic property of ECDSA (as opposed
+   to EdDSA) is required in order to achieve zone privacy.  Records
+   published in a zone are signed using a derived private key as
+   described in Section 4.  The public key "zk" is used to uniquely
+   identify and refer to the zone and is thus called "zone key".  In the
+   following, we use the following naming convention for out
+   cryptographic primitives:
 
-   A GNS resource record holds the data of a specific record in a zone.
-   The resource record format is defined as follows:
+   d  is a private key.  It is defined in [RFC8032] as a b-bit string.
+      In our case, b is 256.
 
 
 
@@ -114,6 +114,20 @@ Schanzenbach, et al.     Expires 24 January 2020           
     [Page 2]
 Internet-Draft             The GNU Name System                 July 2019
 
 
+   p  is the prime of edwards25519 as defined in [RFC8032].
+
+   B  is the group generator of the elliptic curve as defined in
+      [RFC8032] for EdDSA.
+
+   zk  is the ECDSA public key corresponding to d.  It is defined in
+      [RFC6979] as the curve point d*B where B is the group generator of
+      the elliptic curve.
+
+3.  Resource records
+
+   A GNS resource record holds the data of a specific record in a zone.
+   The resource record format is defined as follows:
+
         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                   EXPIRATION                  |
@@ -148,6 +162,14 @@ Internet-Draft             The GNU Name System             
    July 2019
    DATA  The resource record data payload.  The contents are defined by
       the respective type of the resource record.
 
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 3]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    Flags indicate metadata surrounding the resource record.  A flag
    value of 0 indicates that all flags are unset.  The following
    illustrates the flag distribution in the 32-bit flag value of a
@@ -162,31 +184,31 @@ Internet-Draft             The GNU Name System            
     July 2019
 
    where:
 
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 3]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
-   SHADOW  If this flag is set, this record should not be used unless
-      all (other) records with an absolute expiration time have expired.
+   SHADOW  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 cached before the transition becomes active.
 
    EXPREL  The expiration time value of the record is a relative time
-      and not an absolute time.  This flag should never be encountered
-      by a resolver for records resolved from the DHT.
+      (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
+      private records of a zone hosted locally.
 
    PRIVATE  This is a private record of this peer and it should thus not
-      be handed out to other peers.  This flag should never be
-      encountered by a resolver for records resolved from the DHT.
+      be published in the DHT.  Thus, this flag should never be
+      encountered by a resolver for records obtained from the DHT.
+      Private records should still be considered just like regular
+      records when resolving labels in local zones.
 
 3.1.  PKEY
 
    In GNS, a delegation of a label to a zone is represented through a
    PKEY record.  A PKEY resource record contains the public key of the
    zone to delegate to.  A PKEY record MUST be the only record under a
-   label.  No other records are allowed.  The a PKEY DATA entry has the
+   label.  No other records are allowed.  A PKEY DATA entry has the
    following format:
 
          0     8     16    24    32    40    48    56
@@ -197,6 +219,13 @@ Internet-Draft             The GNU Name System             
    July 2019
          |                                               |
          +-----+-----+-----+-----+-----+-----+-----+-----+
 
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 4]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
                                   Figure 3
 
 3.2.  GNS2DNS
@@ -206,26 +235,18 @@ Internet-Draft             The GNU Name System            
     July 2019
    continue with in DNS followed by a DNS server.  Both names are in the
    format defined in [RFC1034] for DNS names.  If a resolver encounters
    a GNS2DNS record it is expected that it first resolves the IP(s) of
-   the DNS servers using DNS.  Then, the encountered DNS name is
-   resolved by querying the name server(s).  The a GNS2DNS DATA entry
+   the DNS server(s).  GNS2DNS records MAY contain numeric IPv4 or IPv6
+   addresses, allowing the resolver to skip this step.  The DNS server
+   names may themselves be names in GNS or DNS.  If the DNS server name
+   ends in ".+", the rest of the name is to be interpreted relative to
+   the zone of the GNS2DNS record.  Then, the DNS name from the GNS2DNS
+   record is appended to the remainder of the name to be resolved, and
+   resolved by querying the name server(s).  Multiple GNS2DNS records
+   may be stored under the same label, in which case the resolve MUST
+   try all of them.  However, if multiple GNS2DNS records are present,
+   the DNS name MUST be identical for all of them.  A GNS2DNS DATA entry
    has the following format:
 
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 4]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
          0     8     16    24    32    40    48    56
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                    DNS NAME                   |
@@ -243,15 +264,24 @@ Internet-Draft             The GNU Name System            
     July 2019
 
 3.3.  LEHO
 
-   As names in GNS are not globally unique, established practices such
-   as virtual hosting do not apply directly.  In order to support such
-   use cases, GNS support a legacy hostname record which can be used by
-   applications (e.g.  HTTP clients) in order to provide the necessary
-   information.  The resource record contains a string which is not
-   0-terminated representing the legacy hostname to use.  It is expected
-   to be found together in a single resource record with an IPv4 or IPv6
+   Legacy hostname records can be used by applications that are expected
+   to supply a DNS name on the application layer.  The most common use
+   case is HTTP virtual hosting, which as-is would not work with GNS
+   names as those may not be globally unique.  A LEHO resource record
+   contains a string (which is not 0-terminated) representing the legacy
+   hostname to use (FIXME: in UTF-8 or PUNY?).  It is expected to be
+   found together in a single resource record with an IPv4 or IPv6
    address.  A LEHO DATA entry has the following format:
 
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 5]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
          0     8     16    24    32    40    48    56
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                 LEGACY HOSTNAME               |
@@ -264,29 +294,27 @@ Internet-Draft             The GNU Name System            
     July 2019
 
 3.4.  BOX
 
-   Record type used to box up SRV and TLSA records.  For example, a TLSA
-   record for "_https._tcp.foo.gnu" will be stored under "foo.gnu" as a
-   BOX record with service 443 (https) and protocol 6 (tcp) and
-   record_type "TLSA".  When a BOX record is received, a GNS resolver
-   must unbox it if the name contained "_SERVICE._PROTO", otherwise it
-   is left untouched.  This is done to ensure that TLSA (and SRV)
-   records do not require a separate network request, thus making TLSA
-   records inseparable from the corresponding A/AAAA/VPN/etc. records.
-   A BOX DATA entry has the following format:
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 5]
-
-Internet-Draft             The GNU Name System                 July 2019
-
+   In GNS, every "." in a name delegates to another zone, and GNS
+   lookups are expected to return all of the required useful information
+   in one record set.  This is incompatible with the special labels used
+   by DNS for SRV and TLSA records.  Thus, GNS defines the BOX record
+   format to box up SRV and TLSA records and include them in the record
+   set of the label they are associated with.  For example, a TLSA
+   record for "_https._tcp.foo.gnu" will be stored in the record set of
+   "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
+   (PROTO) 6 (tcp) and record_type "TLSA".  When a BOX record is
+   received, a GNS resolver must unbox it if the name to be resolved
+   continues with "_SERVICE._PROTO", otherwise it is to be left
+   untouched.  This way, TLSA (and SRV) records do not require a
+   separate network request, and TLSA records become inseparable from
+   the corresponding address records.  A BOX DATA entry has the
+   following format:
 
          0     8     16    24    32    40    48    56
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   PROTO   |    SVC    |       TYPE            |
          +-----------+-----------------------------------+
-         |                   RECORD                      |
+         |                 RECORD DATA                   |
          /                                               /
          /                                               /
          |                                               |
@@ -301,7 +329,17 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    TYPE  Record type of the boxed record.  In network byte order.
 
-   RECORD  The boxed record in a format as defined in Section 3.
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 6]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
+   RECORD DATA  This is the "DATA" format of TYPE as defined for the
+      respective TYPE in DNS.
 
 4.  Publishing records
 
@@ -331,13 +369,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    h  is the HKDF expansion result.  The expansion info is a
       concatenation of the label and string "gns".
 
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 6]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    d  is the private zone key as defined in [RFC8032].
 
    P  is the base point of the curve Ed25519 as defined in [RFC8032].
@@ -355,37 +386,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    q  Is the DHT key under which the resource records block is
       published.  It is the SHA512 hash over the public key "zk_h"
       corresponding to the derived private key "d_h".
-
-4.2.  Resource records block
-
-   GNS records are grouped by their labels and published as a single
-   block in the DHT.  The contained resource records are encrypted using
-   a symmetric encryption scheme.  A GNS resource records block has the
-   following format:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 
@@ -394,6 +394,13 @@ Schanzenbach, et al.     Expires 24 January 2020           
     [Page 7]
 Internet-Draft             The GNU Name System                 July 2019
 
 
+4.2.  Resource records block
+
+   GNS records are grouped by their labels and published as a single
+   block in the DHT.  The contained resource records are encrypted using
+   a symmetric encryption scheme.  A GNS resource records block has the
+   following format:
+
              0     8     16    24    32    40    48    56
              +-----+-----+-----+-----+-----+-----+-----+-----+
              |                   SIGNATURE                   |
@@ -434,14 +441,7 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    SIZE  A 32-bit value containing the length of the signed data
       following the PUBLIC KEY field in network byte order.  This value
-      always includes the length of the fields SIZE (4), PURPOSE (4) and
-      EXPIRATION (8) in addition to the length of the BDATA.
 
-   PURPOSE  A 32-bit signature purpose flag.  This field MUST be 15 (in
-      network byte order).
-
-   EXPIRATION  The resource records block expiration time.  This is the
-      expiration time of the resource record contained within this block
 
 
 
@@ -450,6 +450,14 @@ Schanzenbach, et al.     Expires 24 January 2020           
     [Page 8]
 Internet-Draft             The GNU Name System                 July 2019
 
 
+      always includes the length of the fields SIZE (4), PURPOSE (4) and
+      EXPIRATION (8) in addition to the length of the BDATA.
+
+   PURPOSE  A 32-bit signature purpose flag.  This field MUST be 15 (in
+      network byte order).
+
+   EXPIRATION  The resource records block expiration time.  This is the
+      expiration time of the resource record contained within this block
       with the smallest expiration time.  If a records block includes
       shadow records, then the *maximum* expiration time of all shadow
       records with matching type and the expiration times of the non-
@@ -487,6 +495,17 @@ Internet-Draft             The GNU Name System             
    July 2019
    vector "IV" for the symmetric encryption/decryption are derived as
    follows:
 
+
+
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 9]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
            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);
@@ -499,13 +518,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    the initialization vector.  We divide the resulting keying material
    "K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":
 
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 9]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
              0     8     16    24    32    40    48    56
              +-----+-----+-----+-----+-----+-----+-----+-----+
              |                    AES KEY (Kaes)             |
@@ -545,18 +557,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
 Schanzenbach, et al.     Expires 24 January 2020               [Page 10]
 
 Internet-Draft             The GNU Name System                 July 2019
@@ -593,10 +593,11 @@ Internet-Draft             The GNU Name System            
     July 2019
    RR COUNT  A 32-bit value containing the number of resource records
       which are following in network byte order.
 
-   PADDING  The padding MUST contain the 0 value in all octets.  Not
-      applicable for PKEY records.  The padding MUST ensure that the
-      size of the RDATA is a power of two.  The only excption is the
-      PKEY record type, which is never padded.
+   PADDING  The padding MUST contain the value 0 in all octets.  The
+      padding MUST ensure that the size of the RDATA is a power of two.
+      As a special exception, record sets with (only) a PKEY record type
+      are never padded.  Note that a record set with a PKEY record MUST
+      NOT contain other records.
 
    is followed by a set of resource records with the respective formats
    defined in Section 3.
@@ -612,7 +613,6 @@ Internet-Draft             The GNU Name System              
   July 2019
 
 
 
-
 Schanzenbach, et al.     Expires 24 January 2020               [Page 11]
 
 Internet-Draft             The GNU Name System                 July 2019
@@ -642,30 +642,30 @@ Internet-Draft             The GNU Name System            
     July 2019
          label := "mail"
 
          d :=
-         7ac77c287b9f1971
-         1dcb770ae4b5210d
-         e84f283b903393f8
-         a09db3f347bf7818
+         71199f7b287cc77a
+         0d21b5e40a77cb1d
+         f89333903b284fe8
+         1878bf47f3b39da0
 
          zk (public zone key) :=
-         7e5d026d4911f9df
-         993e15193dc08508
-         ca9e71ea233f214f
-         2e080e41dc32fc17
+         dff911496d025d7e
+         0885c03d19153e99
+         4f213f23ea719eca
+         17fc32dc410e082e
 
          h :=
-         540ef99c5a27f32a
-         b96fe70b93f7dbf2
-         a68c6f41b1807c5e
-         b959b71f8ece50dc
-         9b7ec146f5dcdcfe
-         53c0552863234f4c
-         33dcf484f6e96866
-         ee0f2b39276b656d
+         2af3275a9cf90e54
+         f2dbf7930be76fb9
+         5e7c80b1416f8ca6
+         dc50ce8e1fb759b9
+         fedcdcf546c17e9b
+         4c4f23632855c053
+         6668e9f684f4dc33
+         6d656b27392b0fee
 
          d_h :=
-         3376c182f461fb01
-         f3e009254c1c6177
+         01fb61f482c17633
+         77611c4c2509e0f3
 
 
 
@@ -674,44 +674,44 @@ Schanzenbach, et al.     Expires 24 January 2020          
     [Page 12]
 Internet-Draft             The GNU Name System                 July 2019
 
 
-         bd105c40e4e7b081
-         182ed3f702c81700
+         81b0e7e4405c10bd
+         0017c802f7d32e18
 
          zk_h (derived zone key) :=
-         e0aa0e6ca514b58c
-         dde43ea658517456
-         6e325e54b93c8576
-         9182810f92fad776
+         8cb514a56c0eaae0
+         56745158a63ee4dd
+         76853cb9545e326e
+         76d7fa920f818291
 
          q (query key) :=
-         81d65adced4dce6f
-         3b7e7610339ae2f4
-         bae26c271bbc388b
-         a320e1f19db4f19b
-         6f4168fbdfc9ec20
-         df3bad78d89a7211
-         d720b62626dbb4d0
-         a3663c39e404068e
+         6fce4deddc5ad681
+         f4e29a3310767e3b
+         8b38bc1b276ce2ba
+         9bf1b49df1e120a3
+         20ecc9dffb68416f
+         11729ad878ad3bdf
+         d0b4db2626b620d7
+         8e0604e4393c66a3
 
          AES_KEY :=
-         0d157a081ad2efaf
-         a502da4e1a745767
-         214ba46ba87cdf65
-         01af1e07c006813f
+         afefd21a087a150d
+         6757741a4eda02a5
+         65df7ca86ba44b21
+         3f8106c0071eaf01
 
          AES_IV :=
-         7aad9fbc29b908a8
-         7ad7be3234be6b68
+         a808b929bc9fad7a
+         686bbe3432bed77a
 
          TWOFISH_KEY :=
-         f40b1df09d08d0c9
-         2873cc2c4bdbc8e4
-         d259ae11a8e82534
-         79a4d2857274e299
+         c9d0089df01d0bf4
+         e4c8db4b2ccc7328
+         3425e8a811ae59d2
+         99e2747285d2a479
 
          TWOFISH_IV :=
-         f936d2a989e11b07
-         d481c2b84b65a3b4
+         071be189a9d236f9
+         b4a3654bb8c281d4
 
          RDATA :=
          0000000100059412 RR COUNT | EXPIRA-
@@ -745,30 +745,30 @@ Internet-Draft             The GNU Name System            
     July 2019
          713f0a0d
 
          SIGNATURE :=
-         dee65fe070b05c05 r
-         dddeb4e5504a69ad
-         654f00aedbcbfdb9
-         54bba3c5a99bc9af___________
-         33ee8046a331e707 s
-         b7d2a7edbfe70dae
-         541b8b004a856b8c
-         469fbaf5394fdf10
+         055cb070e05fe6de r
+         ad694a50e5b4dedd
+         b9fdcbdbae004f65
+         afc99ba9c5a3bb54___________
+         07e731a34680ee33 s
+         ae0de7bfeda7d2b7
+         8c6b854a008b1b54
+         10df4f39f5ba9f46
 
          BLOCK :=
-         dee65fe070b05c05 SIGNATURE
-         dddeb4e5504a69ad
-         654f00aedbcbfdb9
-         54bba3c5a99bc9af
-         33ee8046a331e707
-         b7d2a7edbfe70dae
-         541b8b004a856b8c
-         469fbaf5394fdf10____________
-         e0aa0e6ca514b58c zk_h
-         dde43ea658517456
-         6e325e54b93c8576
-         9182810f92fad776____________
-         540000000f000000 SIZE (=84) | PURPOSE (=15)
-         5be2dd0912940500 EXPIRATION
+         055cb070e05fe6de SIGNATURE
+         ad694a50e5b4dedd
+         b9fdcbdbae004f65
+         afc99ba9c5a3bb54
+         07e731a34680ee33
+         ae0de7bfeda7d2b7
+         8c6b854a008b1b54
+         10df4f39f5ba9f46____________
+         8cb514a56c0eaae0 zk_h
+         56745158a63ee4dd
+         76853cb9545e326e
+         76d7fa920f818291____________
+         000000540000000f SIZE (=84) | PURPOSE (=15)
+         0005941209dde25b EXPIRATION
          d99d08fa123da096 BDATA
          66c2fb9bf020a85d
          e80818d0a84059a8
@@ -843,10 +843,10 @@ Internet-Draft             The GNU Name System            
     July 2019
 
 
    Christian Grothoff
-   GNUnet e.V.
-   Boltzmannstrasse 3
-   85748 Garching
-   Germany
+   Berner Fachhochschule
+   Hoeheweg 80
+   CH-2501 Biel/Bienne
+   Switzerland
 
    Email: address@hidden
 
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 86ac030..4da810c 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -82,16 +82,41 @@
    <name>Zones</name>
    <t>
     A zone in GNS is defined by a public/private ECC key pair (d,zk),
-    where d is the private key and
-    zk the corresponding public key.
-    GNS uses the Ed25519 EC parameters as defined in <xref target="RFC8032" />.
-    GNS combines the EC parameters of Ed25519 with the ECDSA scheme
-    defined in <xref target="RFC6979" /> in order to achieve zone privacy.
+    where d is the private key and zk the corresponding public key.
+    GNS combines the EC parameters of Ed25519 (<xref target="RFC8032" />)
+    with the ECDSA scheme (<xref target="RFC6979" />).
+    The deterministic property of ECDSA (as opposed to EdDSA) is required
+    in order to achieve zone privacy.
+    Records published in a zone are signed using a derived private key
+    as described in <xref target="publish" />.
     The public key "zk" is used to uniquely identify and refer to the zone and
     is thus called "zone key".
-    Records published in the zone are signed using a private key derived
-    from "d" as described in <xref target="publish" />.
-   </t>
+    In the following, we use the following naming convention for out
+    cryptographic primitives:
+  </t>
+   <dl>
+    <dt>d</dt>
+    <dd>
+      is a private key. It is defined in <xref target="RFC8032" /> as a b-bit
+      string. In our case, b is 256.
+    </dd>
+    <dt>p</dt>
+    <dd>
+      is the prime of edwards25519 as defined in <xref target="RFC8032" />.
+    </dd>
+    <dt>B</dt>
+    <dd>
+      is the group generator of the elliptic curve as defined in
+      <xref target="RFC8032" /> for EdDSA.
+    </dd>
+    <dt>zk</dt>
+    <dd>
+      is the ECDSA public key corresponding to d. It is defined in
+      <xref target="RFC6979" /> as the curve point d*B where B is the group
+      generator of the elliptic curve.
+    </dd>
+ </dl>
+
   </section>
   <section anchor="rrecords" numbered="true" toc="default">
     <name>Resource records</name>

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]