[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: update hkdf
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: update hkdf |
|
Date: |
Wed, 11 Sep 2019 10:24:34 +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 377ab9c update hkdf
377ab9c is described below
commit 377ab9c760551b658c4256f9a3ebc692148e084f
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Wed Sep 11 10:22:42 2019 +0200
update hkdf
---
draft-schanzen-gns.html | 64 +++++++++-------
draft-schanzen-gns.txt | 196 ++++++++++++++++++++++++------------------------
draft-schanzen-gns.xml | 64 +++++++++-------
3 files changed, 172 insertions(+), 152 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 0cd46ee..8f7f3c4 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1134,15 +1134,14 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-2" class="section-number selfRef">2. </a><a
href="#name-zones" class="section-name selfRef">Zones</a>
</h2>
<p id="section-2-1">
- A zone in GNS is defined by a public/private ECC key pair (x,y), where
x
- is the private key and y the public key.
+ A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ where P is the generator of an elliptic curve, x is the private key and
+ x*P the corresponding public key.
The keys are constructed using the Curve25519 ECC scheme as defined in
<span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.
- The schemes defines that "y := x*P" where "P" is the generator of the
- respective elliptic curve.
- The public key "y" is used to uniquely identify and refer to the zone.
+ The public key "x*P" is used to uniquely identify and refer to the
zone.
Records published in the zone are signed using a private key derived
- from the private key "d" as described in <a href="#publish"
class="xref">Section 4</a>.<a href="#section-2-1" class="pilcrow">¶</a></p>
+ from the private key "x" as described in <a href="#publish"
class="xref">Section 4</a>.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rrecords">
@@ -1282,24 +1281,32 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
together in a single block in the DHT.
A resource records block is published under a key which is derived from
the respective label of the contained records.
- Given a label "l", the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
+ Given a label, the DHT key "q" is derived as follows:<a
href="#section-4-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4-2">
<pre>
- h := HKDF ("key-derivation", l|y|"gns")
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d := h*x mod p
- q := sha512 (d*P)
+ q := SHA512 (d*P)
</pre><a href="#section-4-2" class="pilcrow">¶</a>
</div>
<p id="section-4-3">
- where:<a href="#section-4-3" class="pilcrow">¶</a></p>
+ We use a hash-based key derivation function (HKDF) as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.<a href="#section-4-3"
class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4-4">
<dt id="section-4-4.1">h</dt>
<dd id="section-4-4.2">
- is a SHA512 hash over the label "l" and public key "y".<a
href="#section-4-4.2" class="pilcrow">¶</a>
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public key "x*P" as initial keying
+ material. The label and string "gns" are concatenated and used in the
+ HKDF expansion phase.<a href="#section-4-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-4-4.3">d</dt>
<dd id="section-4-4.4">
- is a private key derived from the zone key x using the hash "h".<a
href="#section-4-4.4" class="pilcrow">¶</a>
+ is a private key derived from the zone key "x" using the keying
+ material "h" (512 bit) and "p" is a prime as defined in
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-4-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-4-4.5">q</dt>
<dd id="section-4-4.6">
@@ -1394,29 +1401,32 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-4.2-1">
Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label "l"
+ en-/decrypt "BDATA". The keys are derived from the record label
and a public key "d*P", where "d" is an ECDSA private key and "P"
- is the EC generator. "d" and "dG" are derived from the
- public/private key pair "x,y" of a GNS zone.
- Both "l" and "P" are implicity known by the GNS resolver.
- The key material "K" and initialization vector "IV"
+ is the EC generator. "d" is derived from the private key "x" of a GNS
+ zone.
+ Both label and public key and "x*P" are implicity known by a GNS
+ resolver while "d*P" is provided within the resource records block.
+ The keying material "K" and initialization vector "IV"
are derived as follows:<a href="#section-4.2-1"
class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-2">
<pre>
- h := HKDF ("key-derivation", l|y|"gns")
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
d := h*x mod p
- K := HKDF (d*P, l|"gns-aes-ctx-key")
- IV := HKDF (d*P, l|"gns-aes-ctx-iv")
+ PRK_kiv := HKDF-Extract (d*P, l)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
</pre><a href="#section-4.2-2" class="pilcrow">¶</a>
</div>
<p id="section-4.2-3">
- "HKDF" is a hash-based key derivation function as defined in
+ We use a hash-based key derivation function (HKDF) as defined in
<span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use
HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase as proposed in
- (paper). The first argument for HKDF is the salt and the second
- argument is the concatenated, serialized source key material.
- We divide the resulting 512-bit "K" into a 256-bit AES key "Kaes"
- and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.2-3"
class="pilcrow">¶</a></p>
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.2-3"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-4.2-4.1">
@@ -1458,7 +1468,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</div>
<p id="section-4.2-7">
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in CFB (ref) mode.<a
href="#section-4.2-7" class="pilcrow">¶</a></p>
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.2-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.2-8">
<pre>
RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index c2be767..525fb95 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -72,9 +72,9 @@ Table of Contents
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 8
8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 8
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 10. Normative References . . . . . . . . . . . . . . . . . . . . 8
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . 9
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
@@ -89,14 +89,13 @@ Table of Contents
2. Zones
- A zone in GNS is defined by a public/private ECC key pair (x,y),
- where x is the private key and y the public key. The keys are
- constructed using the Curve25519 ECC scheme as defined in [RFC7748].
- The schemes defines that "y := x*P" where "P" is the generator of the
- respective elliptic curve. The public key "y" is used to uniquely
- identify and refer to the zone. Records published in the zone are
- signed using a private key derived from the private key "d" as
- described in Section 4.
+ A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ where P is the generator of an elliptic curve, x is the private key
+ and x*P the corresponding public key. The keys are constructed using
+ the Curve25519 ECC scheme as defined in [RFC7748]. The public key
+ "x*P" is used to uniquely identify and refer to the zone. Records
+ published in the zone are signed using a private key derived from the
+ private key "x" as described in Section 4.
3. Resource records
@@ -109,6 +108,7 @@ Table of Contents
+
Schanzenbach Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
@@ -202,22 +202,22 @@ Internet-Draft The GNU Name System
July 2019
Resource records are grouped by their respective labels and published
together in a single block in the DHT. A resource records block is
published under a key which is derived from the respective label of
- the contained records. Given a label "l", the DHT key "q" is derived
- as follows:
+ the contained records. Given a label, the DHT key "q" is derived as
+ follows:
- h := HKDF ("key-derivation", l|y|"gns")
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d := h*x mod p
- q := sha512 (d*P)
-
- where:
-
- h is a SHA512 hash over the label "l" and public key "y".
+ q := SHA512 (d*P)
- d is a private key derived from the zone key x using the hash "h".
+ We use a hash-based key derivation function (HKDF) as defined in
+ [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
+ SHA256 for the expansion phase.
- q Is the DHT key under which the resource records block is
- published. It is the SHA512 hash over the public key "d*P"
- corresponding to the derived private key "d".
+ h is key material retrieved using an HKDF using the string "key-
+ derivation" as salt and the public key "x*P" as initial keying
+ material. The label and string "gns" are concatenated and used in
+ the HKDF expansion phase.
@@ -226,6 +226,13 @@ Schanzenbach Expires 24 January 2020
[Page 4]
Internet-Draft The GNU Name System July 2019
+ d is a private key derived from the zone key "x" using the keying
+ material "h" (512 bit) and "p" is a prime as defined in [RFC7748].
+
+ q Is the DHT key under which the resource records block is
+ published. It is the SHA512 hash over the public key "d*P"
+ corresponding to the derived private key "d".
+
4.1. Resource records block
GNS records are grouped by their labels are published as a single
@@ -266,14 +273,7 @@ Internet-Draft The GNU Name System
July 2019
ECDSA signature over the data following the PUBLIC KEY field. The
signature is create using the derived private key "d".
- PUBLIC KEY The 256-bit ECC public key "d*P" to be used to verify
- SIGNATURE.
-
- BDATA SIZE A 32-bit value containing the length of the following
- data (PURPOSE, EXPIRATION, BDATA) in network byte order.
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
- network byte order).
@@ -282,6 +282,15 @@ Schanzenbach Expires 24 January 2020
[Page 5]
Internet-Draft The GNU Name System July 2019
+ PUBLIC KEY The 256-bit ECC public key "d*P" to be used to verify
+ SIGNATURE.
+
+ BDATA SIZE A 32-bit value containing the length of the following
+ data (PURPOSE, EXPIRATION, BDATA) in network byte order.
+
+ 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. This is a 64-bit absolute date
@@ -294,25 +303,40 @@ Internet-Draft The GNU Name System
July 2019
4.2. Block data encryption
Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label "l"
- and a public key "d*P", where "d" is an ECDSA private key and "P" is
- the EC generator. "d" and "dG" are derived from the public/private
- key pair "x,y" of a GNS zone. Both "l" and "P" are implicity known
- by the GNS resolver. The key material "K" and initialization vector
- "IV" are derived as follows:
-
- h := HKDF ("key-derivation", l|y|"gns")
+ en-/decrypt "BDATA". The keys are derived from the record label and
+ a public key "d*P", where "d" is an ECDSA private key and "P" is the
+ EC generator. "d" is derived from the private key "x" of a GNS zone.
+ Both label and public key and "x*P" are implicity known by a GNS
+ resolver while "d*P" is provided within the resource records block.
+ The keying material "K" and initialization vector "IV" are derived as
+ follows:
+
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
d := h*x mod p
- K := HKDF (d*P, l|"gns-aes-ctx-key")
- IV := HKDF (d*P, l|"gns-aes-ctx-iv")
+ PRK_kiv := HKDF-Extract (d*P, l)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
- "HKDF" is a hash-based key derivation function as defined in
+ We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
- SHA256 for the expansion phase as proposed in (paper). The first
- argument for HKDF is the salt and the second argument is the
- concatenated, serialized source key material. We divide the
- resulting 512-bit "K" into a 256-bit AES key "Kaes" and a 256-bit
- TWOFISH key "Ktwo":
+ SHA256 for the expansion phase. The output keying material is 64
+ octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
+ 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 Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -329,15 +353,6 @@ Internet-Draft The GNU Name System
July 2019
Figure 5
-
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
-
Similarly, we divide "IV" into a 128-bit initialization vector IVaes
and a 128-bit initialization vector IVtwo:
@@ -353,13 +368,32 @@ Internet-Draft The GNU Name System
July 2019
Figure 6
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in CFB (ref) mode.
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
The decrypted RDATA has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -386,14 +420,6 @@ Internet-Draft The GNU Name System
July 2019
where:
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
RR COUNT A 32-bit value containing the number of resource records
which are following.
@@ -416,6 +442,14 @@ Internet-Draft The GNU Name System
July 2019
TODO
+
+
+
+Schanzenbach Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
9. IANA Considerations
This will be fun
@@ -441,15 +475,6 @@ Author's Address
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
-
-
-
-
-Schanzenbach Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
Germany
Email: address@hidden
@@ -473,31 +498,6 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index bc55cd1..834d2d8 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -56,15 +56,14 @@
<section anchor="zones" numbered="true" toc="default">
<name>Zones</name>
<t>
- A zone in GNS is defined by a public/private ECC key pair (x,y), where
x
- is the private key and y the public key.
+ A zone in GNS is defined by a public/private ECC key pair (x,x*P),
+ where P is the generator of an elliptic curve, x is the private key and
+ x*P the corresponding public key.
The keys are constructed using the Curve25519 ECC scheme as defined in
<xref target="RFC7748" />.
- The schemes defines that "y := x*P" where "P" is the generator of the
- respective elliptic curve.
- The public key "y" is used to uniquely identify and refer to the zone.
+ The public key "x*P" is used to uniquely identify and refer to the
zone.
Records published in the zone are signed using a private key derived
- from the private key "d" as described in <xref target="publish" />.
+ from the private key "x" as described in <xref target="publish" />.
</t>
</section>
<section anchor="rrecords" numbered="true" toc="default">
@@ -184,24 +183,32 @@
together in a single block in the DHT.
A resource records block is published under a key which is derived from
the respective label of the contained records.
- Given a label "l", the DHT key "q" is derived as follows:
+ Given a label, the DHT key "q" is derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- h := HKDF ("key-derivation", l|y|"gns")
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d := h*x mod p
- q := sha512 (d*P)
+ q := SHA512 (d*P)
]]></artwork>
<t>
- where:
+ We use a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
</t>
<dl>
<dt>h</dt>
<dd>
- is a SHA512 hash over the label "l" and public key "y".
+ is key material retrieved using an HKDF using the string
+ "key-derivation" as salt and the public key "x*P" as initial keying
+ material. The label and string "gns" are concatenated and used in the
+ HKDF expansion phase.
</dd>
<dt>d</dt>
<dd>
- is a private key derived from the zone key x using the hash "h".
+ is a private key derived from the zone key "x" using the keying
+ material "h" (512 bit) and "p" is a prime as defined in
+ <xref target="RFC7748" />.
</dd>
<dt>q</dt>
<dd>
@@ -287,28 +294,31 @@
<name>Block data encryption</name>
<t>
Given a GNS record block a symmetric encryption scheme is used to
- en-/decrypt "BDATA". The keys are derived from the record label "l"
+ en-/decrypt "BDATA". The keys are derived from the record label
and a public key "d*P", where "d" is an ECDSA private key and "P"
- is the EC generator. "d" and "dG" are derived from the
- public/private key pair "x,y" of a GNS zone.
- Both "l" and "P" are implicity known by the GNS resolver.
- The key material "K" and initialization vector "IV"
+ is the EC generator. "d" is derived from the private key "x" of a GNS
+ zone.
+ Both label and public key and "x*P" are implicity known by a GNS
+ resolver while "d*P" is provided within the resource records block.
+ The keying material "K" and initialization vector "IV"
are derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- h := HKDF ("key-derivation", l|y|"gns")
+ PRK_h := HKDF-Extract ("key-derivation", x*P)
+ h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
d := h*x mod p
- K := HKDF (d*P, l|"gns-aes-ctx-key")
- IV := HKDF (d*P, l|"gns-aes-ctx-iv")
+ PRK_kiv := HKDF-Extract (d*P, l)
+ K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
+ IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
]]></artwork>
<t>
- "HKDF" is a hash-based key derivation function as defined in
+ We use a hash-based key derivation function (HKDF) as defined in
<xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase as proposed in
- (paper). The first argument for HKDF is the salt and the second
- argument is the concatenated, serialized source key material.
- We divide the resulting 512-bit "K" into a 256-bit AES key "Kaes"
- and a 256-bit TWOFISH key "Ktwo":
+ phase and HMAC-SHA256 for the expansion phase.
+ The output keying material is 64 octets (512 bit) for the symmetric
+ keys and 32 octets (256 bit) for the initialization vector.
+ We divide the resulting keying material "K" into a 256-bit AES key
+ "Kaes" and a 256-bit TWOFISH key "Ktwo":
</t>
<figure anchor="figure_hkdf_keys">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -347,7 +357,7 @@
<t>
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in CFB (ref) mode.
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
--
To stop receiving notification emails like this one, please contact
address@hidden.
- [GNUnet-SVN] [lsd0001] branch master updated: update hkdf,
gnunet <=