[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: add test vector (thx bfix)
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: add test vector (thx bfix) |
|
Date: |
Thu, 03 Oct 2019 17:40:50 +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 fa5d13b add test vector (thx bfix)
fa5d13b is described below
commit fa5d13b7d56c50f81a86a3a5ea7c4aa710892f57
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Thu Oct 3 17:38:40 2019 +0200
add test vector (thx bfix)
---
draft-schanzen-gns.html | 85 ++++++++++++++----
draft-schanzen-gns.txt | 234 ++++++++++++++++++++++++++++++------------------
draft-schanzen-gns.xml | 37 +++++++-
3 files changed, 250 insertions(+), 106 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 76076d1..ef8dea6 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1124,10 +1124,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-iana-considerations" class="xref">IANA
Considerations</a><a href="#section-boilerplate.3-1.9.1"
class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.10">
- <p id="section-boilerplate.3-1.10.1"><a href="#section-10"
class="xref">10</a>. <a href="#name-normative-references"
class="xref">Normative References</a><a href="#section-boilerplate.3-1.10.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.10.1"><a href="#section-10"
class="xref">10</a>. <a href="#name-test-vectors" class="xref">Test
Vectors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.11">
- <p id="section-boilerplate.3-1.11.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors'
Addresses</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.11.1"><a href="#section-11"
class="xref">11</a>. <a href="#name-normative-references"
class="xref">Normative References</a><a href="#section-boilerplate.3-1.11.1"
class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.12">
+ <p id="section-boilerplate.3-1.12.1"><a href="#section-appendix.a"
class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors'
Addresses</a><a href="#section-boilerplate.3-1.12.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
@@ -1274,7 +1277,10 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h3 id="name-pkey">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a
href="#name-pkey" class="section-name selfRef">PKEY</a>
</h3>
-<p id="section-3.2-1">The a PKEY DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
+<p id="section-3.2-1">In GNS, a delegation of a label to a zone is represented
througha 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
+ labels are allows. The a PKEY DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.2-2.1">
@@ -1297,18 +1303,30 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h3 id="name-gns2dns">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a
href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
</h3>
-<p id="section-3.3-1">The a GNS2DNS DATA entry has the following format:<a
href="#section-3.3-1" class="pilcrow">¶</a></p>
+<p id="section-3.3-1">It is possible to delegate a label back into DNS through
a GNS2DNS record.
+ The resource record contains a DNS name for the resolver to continue with
+ in DNS followed by a DNS server. Both names are in the format defined in
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> 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 has the following format:<a href="#section-3.3-1"
class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-4">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
+ | DNS NAME |
+ / /
+ / /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
@@ -1320,7 +1338,14 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<h3 id="name-leho">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-leho" class="section-name selfRef">LEHO</a>
</h3>
-<p id="section-3.4-1">The a LEHO DATA entry has the following format:<a
href="#section-3.4-1" class="pilcrow">¶</a></p>
+<p id="section-3.4-1">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 address.
+ A LEHO DATA entry has the following format:<a href="#section-3.4-1"
class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.4-2.1">
@@ -1328,8 +1353,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
- | |
- | |
+ / /
+ / /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
@@ -1360,7 +1385,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<div class="artwork art-text alignLeft" id="section-4.1-1">
<pre>
PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ h := HKDF-Expand (PRK_h, label, 512 / 8)
x_h := h*x mod p
zk_h := h*zk mod p
q := SHA512 (zk_h)
@@ -1534,9 +1559,10 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
symmetric encryption/decryption are derived as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
- PRK_kiv := HKDF-Extract (zk, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, l, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, l, 256 / 8)
</pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">
@@ -1686,10 +1712,39 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</section>
</div>
<section id="section-10">
+ <h2 id="name-test-vectors">
+<a href="#section-10" class="section-number selfRef">10. </a><a
href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
+ </h2>
+<p id="section-10-1"><a href="#section-10-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-10-2">
+<pre>
+SEED=0f388abc49f99b8675555ad33c3b586a9e06f0f60f6caadeee6fd12226ac2474
+LABEL="home"
+D(private_scalar)=7450f71def6411e0ab0e6a1dfd1d9ccd0eaf71952494ccf51b85ffac5db093c8
+PK(public_key)=23d89a29da0f6808c6b6d5e59cdd6a6fcf3e2bb006f466d5423a935d6b4d7e10
+SK(private_key)=SEED||PK
+H(derived_factor)=071efca7db2850bd6f354ebfe38c5bbfd6ba2f805cd8d3b54edd7f3dd0730d1a
+H*PK(derived_pk)=9f27ad25b5954a467bc65a676b7a6d23b2ef300f7fc70058059e7f29e594b5c1
+QUERY=d18e5efff7646f9c87db4ff5e98df8f53d57b7a813271a488fd84e9e4ecae92636ab831bd17cd7e6c879d04e8a91b55570a94a6fef9ecf3c70207f69a4a8387a
+AES_KEY=033e97f17570004effe7e1b75b167668a3e0c320b7660eef0718d0aaa779164
+AES_IV=b052ae34fac578e9c7e400e712359621
+2FISH_KEY=db5211605614363a4c2e23d96c9b1d3188a1b7cb85802db10ac7cc3f763c1670
+AES_IV=bc63e4b6f47a7254e4f4ff06d263f9d5
+DATA_PLAIN=000000010005af87005b9140000000170000000f00000000000a046d61696c0a686f692d706f6c6c6f69036f726700000000000000000000000000000000000000000000000000
+DATA_ENCRYPED=5fb6552e3959ff9fd80c1b0213dc7ef1f6edb016df693226f0d46dc04a34265bf6eaf8e945a7685dc94913835e03d695d1e307d6e4ce210bf0983af61346c69e69b2c636300fbf
+SIGNED_DATA=000000570000000f0005af87005b9140||DATA_ENCRYPTED
+SIGNATURE=0f560541fb3900c3459efcba85e006a99122725baa1fb50b6ec6210eb815caba0663c95eb9ca1863b13c9320e8637a1168abebc4b916f4fff5bf62aa8d2d56b8
+ </pre><a href="#section-10-2" class="pilcrow">¶</a>
+</div>
+</section>
+<section id="section-11">
<h2 id="name-normative-references">
-<a href="#section-10" class="section-number selfRef">10. </a><a
href="#name-normative-references" class="section-name selfRef">Normative
References</a>
+<a href="#section-11" class="section-number selfRef">11. </a><a
href="#name-normative-references" class="section-name selfRef">Normative
References</a>
</h2>
<dl class="references">
+<dt id="RFC1034">[RFC1034]</dt>
+ <dd>
+<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - concepts and facilities"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1034</span>, <span
class="seriesInfo">DOI 10.17487/RFC1034</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1034";>https://www.rfc-editor.org/info/rfc1034</a>></span>.
</dd>
<dt id="RFC1035">[RFC1035]</dt>
<dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain
names - implementation and specification"</span>, <span class="seriesInfo">STD
13</span>, <span class="seriesInfo">RFC 1035</span>, <span
class="seriesInfo">DOI 10.17487/RFC1035</span>, <time
datetime="1987-11">November 1987</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>></span>.
</dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 0bc791d..d450d34 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -70,14 +70,15 @@ Table of Contents
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 5
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 5
4.2. Resource records block . . . . . . . . . . . . . . . . . 6
- 4.3. Block data encryption and decryption . . . . . . . . . . 7
- 5. Internationalization and Character Encoding . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.3. Block data encryption and decryption . . . . . . . . . . 8
+ 5. Internationalization and Character Encoding . . . . . . . . . 10
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 10
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 10. Normative References . . . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
@@ -108,7 +109,6 @@ Table of Contents
-
Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
@@ -192,7 +192,11 @@ Internet-Draft The GNU Name System
July 2019
3.2. PKEY
- The a PKEY DATA entry has the following format:
+ In GNS, a delegation of a label to a zone is represented througha
+ 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 labels are allows. The a PKEY DATA entry has the
+ following format:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -206,18 +210,14 @@ Internet-Draft The GNU Name System
July 2019
3.3. GNS2DNS
- The a GNS2DNS DATA entry has the following format:
-
- 0 8 16 24 32 40 48 56
- +-----+-----+-----+-----+-----+-----+-----+-----+
- | PUBLIC KEY |
- | |
- | |
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
-
- Figure 4
-
+ It is possible to delegate a label back into DNS through a GNS2DNS
+ record. The resource record contains a DNS name for the resolver to
+ 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
+ has the following format:
@@ -226,15 +226,37 @@ 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 |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / /
+ / /
+ | |
+ +-----------------------------------------------+
+
+ Figure 4
+
3.4. LEHO
- The a LEHO DATA entry has the following format:
+ 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
+ address. A LEHO DATA entry has the following format:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
- | |
- | |
+ / /
+ / /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -251,8 +273,17 @@ Internet-Draft The GNU Name System
July 2019
4.1. Key derivations
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
+
PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ h := HKDF-Expand (PRK_h, label, 512 / 8)
x_h := h*x mod p
zk_h := h*zk mod p
q := SHA512 (zk_h)
@@ -274,14 +305,6 @@ Internet-Draft The GNU Name System
July 2019
label under wich the resource records are published.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
x_h is a private key derived from the zone private key "x" using the
keying material "h" (512 bit) and "p" is the group order as
defined in [RFC8032].
@@ -301,6 +324,20 @@ Internet-Draft The GNU Name System
July 2019
a symmetric encryption scheme. A GNS resource records block has the
following format:
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
@@ -330,14 +367,6 @@ Internet-Draft The GNU Name System
July 2019
where:
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
-
SIGNATURE A 512-bit ECDSA deterministic signature compliant with
[RFC6979]. The signature is computed over the data following the
PUBLIC KEY field. The signature is created using the derived
@@ -356,6 +385,15 @@ Internet-Draft The GNU Name System
July 2019
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. This is a 64-bit absolute date
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
in microseconds since midnight (0 hour), January 1, 1970 in
network byte order.
@@ -386,20 +424,13 @@ Internet-Draft The GNU Name System
July 2019
computing "h" from "x_h" and label and verifying that "zk_h = h*zk".
This step is mandatory to prevent spoofed records to be verified and
decrypted correctly. The keying material "K" and initialization
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
vector "IV" for the symmetric encryption/decryption are derived as
follows:
- PRK_kiv := HKDF-Extract (zk, label)
- K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
- IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, l, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, l, 256 / 8)
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
@@ -408,6 +439,17 @@ 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 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| AES KEY (Kaes) |
@@ -443,15 +485,27 @@ Internet-Draft The GNU Name System
July 2019
RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ The decrypted RDATA has the following format:
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
Internet-Draft The GNU Name System July 2019
- The decrypted RDATA has the following format:
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -496,25 +550,47 @@ Internet-Draft The GNU Name System
July 2019
TODO
+8. Namespace Revocation
+ TODO
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
-8. Namespace Revocation
-
- TODO
-
9. IANA Considerations
This will be fun
-10. Normative References
+10. Test Vectors
+
+
+ SEED=0f388abc49f99b8675555ad33c3b586a9e06f0f60f6caadeee6fd12226ac2474
+ LABEL="home"
+
D(private_scalar)=7450f71def6411e0ab0e6a1dfd1d9ccd0eaf71952494ccf51b85ffac5db093c8
+
PK(public_key)=23d89a29da0f6808c6b6d5e59cdd6a6fcf3e2bb006f466d5423a935d6b4d7e10
+ SK(private_key)=SEED||PK
+
H(derived_factor)=071efca7db2850bd6f354ebfe38c5bbfd6ba2f805cd8d3b54edd7f3dd0730d1a
+
H*PK(derived_pk)=9f27ad25b5954a467bc65a676b7a6d23b2ef300f7fc70058059e7f29e594b5c1
+
QUERY=d18e5efff7646f9c87db4ff5e98df8f53d57b7a813271a488fd84e9e4ecae92636ab831bd17cd7e6c879d04e8a91b55570a94a6fef9ecf3c70207f69a4a8387a
+ AES_KEY=033e97f17570004effe7e1b75b167668a3e0c320b7660eef0718d0aaa779164
+ AES_IV=b052ae34fac578e9c7e400e712359621
+ 2FISH_KEY=db5211605614363a4c2e23d96c9b1d3188a1b7cb85802db10ac7cc3f763c1670
+ AES_IV=bc63e4b6f47a7254e4f4ff06d263f9d5
+
DATA_PLAIN=000000010005af87005b9140000000170000000f00000000000a046d61696c0a686f692d706f6c6c6f69036f726700000000000000000000000000000000000000000000000000
+
DATA_ENCRYPED=5fb6552e3959ff9fd80c1b0213dc7ef1f6edb016df693226f0d46dc04a34265bf6eaf8e945a7685dc94913835e03d695d1e307d6e4ce210bf0983af61346c69e69b2c636300fbf
+ SIGNED_DATA=000000570000000f0005af87005b9140||DATA_ENCRYPTED
+
SIGNATURE=0f560541fb3900c3459efcba85e006a99122725baa1fb50b6ec6210eb815caba0663c95eb9ca1863b13c9320e8637a1168abebc4b916f4fff5bf62aa8d2d56b8
+
+11. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
@@ -535,6 +611,13 @@ Internet-Draft The GNU Name System
July 2019
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
Authors' Addresses
Martin Schanzenbach
@@ -555,13 +638,6 @@ Authors' Addresses
Email: address@hidden
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
-
-
Bernd Fix
GNUnet e.V.
Boltzmannstrasse 3
@@ -593,24 +669,4 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 75ef28c..ddf66a8 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -274,7 +274,7 @@
<name>Key derivations</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
- h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
+ h := HKDF-Expand (PRK_h, label, 512 / 8)
x_h := h*x mod p
zk_h := h*zk mod p
q := SHA512 (zk_h)
@@ -436,10 +436,16 @@
The keying material "K" and initialization vector "IV" for the
symmetric encryption/decryption are derived as follows:
</t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ <!-- OLD VERSION
PRK_kiv := HKDF-Extract (zk, label)
K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
+ -->
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
+ PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
+ K := HKDF-Expand (PRK_k, l, 512 / 8);
+ IV := HKDF-Expand (PRK_iv, l, 256 / 8)
]]></artwork>
<t>
We use a hash-based key derivation function (HKDF) as defined in
@@ -567,6 +573,33 @@
</t>
</section>
<!-- iana -->
+ <section>
+ <name>Test Vectors</name>
+ <t>
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+SEED := 0f388abc49f99b8675555ad33c3b586a9e06f0f60f6caadeee6fd12226ac2474
+label := "home"
+D(private_scalar) :=
7450f71def6411e0ab0e6a1dfd1d9ccd0eaf71952494ccf51b85ffac5db093c8
+zk (Zone Key) :=
23d89a29da0f6808c6b6d5e59cdd6a6fcf3e2bb006f466d5423a935d6b4d7e10
+SK (private_key) := SEED||PK
+h (derived_factor) :=
071efca7db2850bd6f354ebfe38c5bbfd6ba2f805cd8d3b54edd7f3dd0730d1a
+zk_h (derived zone key) :=
9f27ad25b5954a467bc65a676b7a6d23b2ef300f7fc70058059e7f29e594b5c1
+q (query key) :=
d18e5efff7646f9c87db4ff5e98df8f53d57b7a813271a488fd84e9e4ecae92636ab831bd17cd7e6c879d04e8a91b55570a94a6fef9ecf3c70207f69a4a8387a
+AES_KEY := 033e97f17570004effe7e1b75b167668a3e0c320b7660eef0718d0aaa779164
+AES_IV := b052ae34fac578e9c7e400e712359621
+TWOFISH_KEY := db5211605614363a4c2e23d96c9b1d3188a1b7cb85802db10ac7cc3f763c1670
+TWOFISH_IV := bc63e4b6f47a7254e4f4ff06d263f9d5
+RDATA :=
000000010005af87005b9140000000170000000f00000000000a046d61696c0a686f692d706f6c6c6f69036f726700000000000000000000000000000000000000000000000000
+BDATA :=
5fb6552e3959ff9fd80c1b0213dc7ef1f6edb016df693226f0d46dc04a34265bf6eaf8e945a7685dc94913835e03d695d1e307d6e4ce210bf0983af61346c69e69b2c636300fbf
+SIGNATURE :=
0f560541fb3900c3459efcba85e006a99122725baa1fb50b6ec6210eb815caba0663c95eb9ca1863b13c9320e8637a1168abebc4b916f4fff5bf62aa8d2d56b8
+BDATA_SIZE := 00000057
+PURPOSE := 0000000f
+EXPIRATION := 0005af87005b9140
+BLOCK (Resource records block)=SIGNATURE || ZK_H || BDATA_SIZE || PURPOSE ||
EXPIRATION || BDATA
+ ]]></artwork>
+
+ </section>
</middle>
<back>
<references>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: add test vector (thx bfix),
gnunet <=