[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: clarify HKDF
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: clarify HKDF |
|
Date: |
Mon, 09 Sep 2019 22:07:37 +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 1dccf8a clarify HKDF
1dccf8a is described below
commit 1dccf8a5781fe675248f3e1fc75ea8980027608f
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Sep 9 22:05:45 2019 +0200
clarify HKDF
---
draft-schanzen-gns.txt | 38 ++++++++++++------------
draft-schanzen-gns.xml | 79 +++++++++++++++++++++++++++++++++-----------------
2 files changed, 72 insertions(+), 45 deletions(-)
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index e95d1af..1eadf6a 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -65,7 +65,7 @@ Table of Contents
2.1. GNS record blocks . . . . . . . . . . . . . . . . . . . . 2
2.1.1. GNS record block data cryptography . . . . . . . . . 3
2.2. GNS records . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Serialization format . . . . . . . . . . . . . . . . . . 5
2.5. Internationalization and Character Encoding . . . . . . . 5
2.6. Security Considerations . . . . . . . . . . . . . . . . . 5
@@ -174,13 +174,17 @@ Internet-Draft The GNU Name System
July 2019
d := h*x mod n
k := HKDF (P,l)
- "HKDF" is a hash-based key derivation function which derives the
- symmetric AES key "k" from the public key "P" and the record label
- "l".
+ "HKDF" is a hash-based key derivation function as defined in
+ [RFC5869]. For the XTR, we use HMAC-SHA512 and HMAC-SHA256 in PRF as
+ proposed in (paper). Using this HKDF, we derive two symmetric AES
+ keys "Ka,Kt" from the public key "P" and the record label "l". The
+ two symmetric keys are used for a AES+TWOFISH combined cipher:
+
+ RDATA := TWOFISH256(Kt, AES256(Ka, BDATA))
2.2. GNS records
- A single entry in the decrypted BDATA SET has the following format:
+ The RDATA consist of one or more entries in the following format:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -193,7 +197,7 @@ Internet-Draft The GNU Name System
July 2019
+-----+-----+-----+-----+-----+-----+-----+-----+
| RDATA SIZE | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | RDATA |
+ | FLAGS | DATA |
+-----+-----+-----+-----+ |
/ /
/ /
@@ -202,7 +206,7 @@ Internet-Draft The GNU Name System
July 2019
Figure 2
- The a PKEY RDATA has the following format:
+ The a PKEY DATA entry has the following format:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -214,10 +218,6 @@ Internet-Draft The GNU Name System
July 2019
Figure 3
-2.3. Examples
-
- TODO
-
@@ -226,6 +226,10 @@ Schanzenbach Expires 24 January 2020
[Page 4]
Internet-Draft The GNU Name System July 2019
+2.3. Examples
+
+ TODO
+
2.4. Serialization format
TODO (Is this not the same as wire format?)
@@ -252,10 +256,10 @@ Internet-Draft The GNU Name System
July 2019
6. Normative References
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, DOI 10.17487/RFC3986, January 2005,
- <https://www.rfc-editor.org/info/rfc3986>.
+ [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
+ Key Derivation Function (HKDF)", RFC 5869,
+ DOI 10.17487/RFC5869, May 2010,
+ <https://www.rfc-editor.org/info/rfc5869>.
Author's Address
@@ -273,8 +277,4 @@ Author's Address
-
-
-
-
Schanzenbach Expires 24 January 2020 [Page 5]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 403b799..0f7edb7 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -21,7 +21,7 @@
<organization>GNUnet e.V.</organization>
<address>
<postal>
- <street ascii="Boltzmannstrasse 3">Boltzmannstrasse 3</street>
+ <street>Boltzmannstrasse 3</street>
<city>Garching</city>
<code>85748</code>
<country>DE</country>
@@ -63,7 +63,7 @@
<t>A GNS record block has the following format:</t>
<figure anchor="figure_record_block">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 1 2 3 4 5 6 7
+ 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
| |
@@ -106,28 +106,55 @@
<section numbered="true" toc="default">
<name>GNS record block data cryptography</name>
<t>
- Given a GNS record block a symmetric key "k" is used to
- en-/decrypt "BDATA". The key is derived from the record label "l"
and
- the public key "P". Both "l" and "P" are implicity known by the
- GNS resolver. "k" is a 256-bit AES key which is derived as follows.
+ 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 the public key "P". Both "l" and "P" are implicity known by the
+ GNS resolver. The key material "K" is derived as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
h := SHA512 (l,P)
d := h*x mod n
- k := HKDF (P,l)
+ K := HKDF (P,l)
]]></artwork>
<t>
- "HKDF" is a hash-based key derivation function which derives the
- symmetric AES key "k" from the public key "P" and the record label
"l".
+ "HKDF" is a hash-based key derivation function as defined in
+ <xref target="RFC5869" />. For the XTR, we use HMAC-SHA512 and
+ HMAC-SHA256 in PRF as proposed in (paper). Using this HKDF, we
+ derive two symmetric 256-bit keys "Ka,Kt" from "K":
</t>
+ <figure anchor="figure_hddf_keys">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | AES KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TWOFISH KEY |
+ | |
+ | |
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+
+ <t>
+ The two symmetric keys are used for a AES+TWOFISH combined cipher:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ RDATA := TWOFISH256(Kt, AES256(Ka, BDATA))
+ ]]></artwork>
+
</section>
</section>
<section numbered="true" toc="default">
<name>GNS records</name>
- <t>A single entry in the decrypted BDATA SET has the following
format:</t>
+ <t>The RDATA consist of one or more entries in the following
format:</t>
<figure anchor="figure_gnsrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 1 2 3 4 5 6 7
+ 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -138,7 +165,7 @@
+-----+-----+-----+-----+-----+-----+-----+-----+
| RDATA SIZE | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | FLAGS | RDATA |
+ | FLAGS | DATA |
+-----+-----+-----+-----+ |
/ /
/ /
@@ -147,10 +174,10 @@
]]></artwork>
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
- <t>The a PKEY RDATA has the following format:</t>
+ <t>The a PKEY DATA entry has the following format:</t>
<figure anchor="figure_pkeyrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
- 0 1 2 3 4 5 6 7
+ 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
@@ -209,26 +236,26 @@
<back>
<references>
<name>Normative References</name>
- <reference anchor="RFC3986"
target="https://www.rfc-editor.org/info/rfc3986";
xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml";>
+ <reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
<front>
- <title>Uniform Resource Identifier (URI): Generic Syntax</title>
- <seriesInfo name="DOI" value="10.17487/RFC3986"/>
- <seriesInfo name="RFC" value="3986"/>
- <seriesInfo name="STD" value="66"/>
- <author initials="T." surname="Berners-Lee" fullname="T.
Berners-Lee">
- <organization/>
- </author>
- <author initials="R." surname="Fielding" fullname="R. Fielding">
+ <title>
+ HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+ </title>
+ <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
<organization/>
</author>
- <author initials="L." surname="Masinter" fullname="L. Masinter">
+ <author initials="P." surname="Eronen" fullname="P. Eronen">
<organization/>
</author>
- <date year="2005" month="January"/>
+ <date year="2010" month="May"/>
<abstract>
- <t>A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
specification defines the generic URI syntax and a process for resolving URI
references that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet. The URI syntax defines a
grammar that is a superset of all valid URIs, allowing an implementation to
parse the common components of a URI ref [...]
+ <t>
+ This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a
building block in various protocols and applications. The key derivation
function (KDF) is intended to support a wide range of applications and
requirements, and is conservative in its use of cryptographic hash functions.
This document is not an Internet Standards Track specification; it is published
for informational purposes.
+ </t>
</abstract>
</front>
+ <seriesInfo name="RFC" value="5869"/>
+ <seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<!-- <reference anchor="ISO20022">
<front>
--
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: clarify HKDF,
gnunet <=