[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: add aes reference
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: add aes reference |
|
Date: |
Fri, 04 Oct 2019 16:03:00 +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 1657101 add aes reference
1657101 is described below
commit 165710199fc5890714136cc7886f16251b4d78a2
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Fri Oct 4 16:00:49 2019 +0200
add aes reference
---
draft-schanzen-gns.html | 44 ++++++++++++++++++--------------
draft-schanzen-gns.txt | 68 ++++++++++++++++++++++++-------------------------
draft-schanzen-gns.xml | 42 ++++++++++++++++--------------
3 files changed, 82 insertions(+), 72 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 55ffcee..b960c92 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1630,11 +1630,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
in a GNS record block. The keys are derived from the record label
and the zone key "zk".
- The validity of "d" can be checked by 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 vector "IV" for the
- symmetric encryption/decryption are derived as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
+ Upon receiving a resource records block, first the validity of a given
+ "zk_h" MUST be checked by computing "h" from "zk" and label and
+ verifying that both are equal. This step is mandatory to prevent record
+ spoofing.
+ For decryption of the resource records block payload,
+ the key material "K" and initialization vector "IV" for the
+ symmetric en-/decryption are derived:<a href="#section-4.3-1"
class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-2">
<pre>
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
@@ -1644,25 +1646,25 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</pre><a href="#section-4.3-2" class="pilcrow">¶</a>
</div>
<p id="section-4.3-3">
- 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.
+ HKDF is a hash-based key derivation function as defined in
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>.
Specifically, HMAC-SHA512 is used for the
+ extraction 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.
+ keys and 32 octets (256 bit) for the initialization vectors.
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.3-3"
class="pilcrow">¶</a></p>
+ and a 256-bit TWOFISH key:<a href="#section-4.3-3"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
+ | AES KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
+ | TWOFISH KEY |
| |
| |
| |
@@ -1672,18 +1674,18 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
</div>
<p id="section-4.3-5">
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
+ Similarly, we divide "IV" into a 128-bit initialization vector
+ and a 128-bit initialization vector:<a href="#section-4.3-5"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-6.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
+ | AES IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
+ | TWOFISH IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
@@ -1692,11 +1694,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</div>
<p id="section-4.3-7">
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.<a
href="#section-4.3-7" class="pilcrow">¶</a></p>
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode
+ (<span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>).<a
href="#section-4.3-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-8">
<pre>
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
</pre><a href="#section-4.3-8" class="pilcrow">¶</a>
</div>
<p id="section-4.3-9">
@@ -1952,6 +1955,9 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dt id="RFC3629">[RFC3629]</dt>
<dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a
transformation format of ISO 10646"</span>, <span class="seriesInfo">STD
63</span>, <span class="seriesInfo">RFC 3629</span>, <span
class="seriesInfo">DOI 10.17487/RFC3629</span>, <time
datetime="2003-11">November 2003</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>></span>.
</dd>
+<dt id="RFC3826">[RFC3826]</dt>
+ <dd>
+<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino,
F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span
class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in
the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC
3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time
datetime="2004-06">June 2004</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc3826";>https://www.rfc-editor.org/ [...]
<dt id="RFC5869">[RFC5869]</dt>
<dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P.
Eronen</span>, <span class="refTitle">"
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index f3bddbb..44573a4 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -471,25 +471,25 @@ Internet-Draft The GNU Name System
July 2019
A symmetric encryption scheme is used to en-/decrypt the "BDATA"
field in a GNS record block. The keys are derived from the record
- label and the zone key "zk". The validity of "d" can be checked by
- 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
- vector "IV" for the symmetric encryption/decryption are derived as
- follows:
+ label and the zone key "zk". Upon receiving a resource records
+ block, first the validity of a given "zk_h" MUST be checked by
+ computing "h" from "zk" and label and verifying that both are equal.
+ This step is mandatory to prevent record spoofing. For decryption of
+ the resource records block payload, the key material "K" and
+ initialization vector "IV" for the symmetric en-/decryption are
+ derived:
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);
IV := HKDF-Expand (PRK_iv, label, 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-
+ HKDF is a hash-based key derivation function as defined in [RFC5869].
+ Specifically, HMAC-SHA512 is used for the extraction 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":
-
+ the initialization vectors. We divide the resulting keying material
+ "K" into a 256-bit AES key and a 256-bit TWOFISH key:
@@ -508,12 +508,12 @@ Internet-Draft The GNU Name System
July 2019
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
+ | AES KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
+ | TWOFISH KEY |
| |
| |
| |
@@ -521,25 +521,26 @@ Internet-Draft The GNU Name System
July 2019
Figure 8
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:
+ Similarly, we divide "IV" into a 128-bit initialization vector and a
+ 128-bit initialization vector:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
+ | AES IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
+ | TWOFISH IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 9
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode
+ ([RFC3826]).
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV,
BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV,
RDATA))
The decrypted RDATA has the following format:
@@ -556,7 +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
@@ -800,6 +800,12 @@ Internet-Draft The GNU Name System
July 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
+ [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
+ Advanced Encryption Standard (AES) Cipher Algorithm in the
+ SNMP User-based Security Model", RFC 3826,
+ DOI 10.17487/RFC3826, June 2004,
+ <https://www.rfc-editor.org/info/rfc3826>.
+
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
@@ -828,12 +834,6 @@ Authors' Addresses
Martin Schanzenbach
GNUnet e.V.
- Boltzmannstrasse 3
- 85748 Garching
- Germany
-
- Email: address@hidden
-
@@ -842,6 +842,13 @@ Schanzenbach, et al. Expires 24 January 2020
[Page 15]
Internet-Draft The GNU Name System July 2019
+ Boltzmannstrasse 3
+ 85748 Garching
+ Germany
+
+ Email: address@hidden
+
+
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
@@ -878,13 +885,6 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-
-
-
-
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 7125a28..8d52ff3 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -508,11 +508,13 @@
A symmetric encryption scheme is used to en-/decrypt the "BDATA" field
in a GNS record block. The keys are derived from the record label
and the zone key "zk".
- The validity of "d" can be checked by 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 vector "IV" for the
- symmetric encryption/decryption are derived as follows:
+ Upon receiving a resource records block, first the validity of a given
+ "zk_h" MUST be checked by computing "h" from "zk" and label and
+ verifying that both are equal. This step is mandatory to prevent record
+ spoofing.
+ For decryption of the resource records block payload,
+ the key material "K" and initialization vector "IV" for the
+ symmetric en-/decryption are derived:
</t>
<!-- OLD VERSION
PRK_kiv := HKDF-Extract (zk, label)
@@ -526,24 +528,24 @@
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
]]></artwork>
<t>
- 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.
+ HKDF is a hash-based key derivation function as defined in
+ <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used for the
+ extraction 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.
+ keys and 32 octets (256 bit) for the initialization vectors.
We divide the resulting keying material "K" into a 256-bit AES key
- "Kaes" and a 256-bit TWOFISH key "Ktwo":
+ and a 256-bit TWOFISH key:
</t>
<figure anchor="figure_hkdf_keys">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES KEY (Kaes) |
+ | AES KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH KEY (Ktwo) |
+ | TWOFISH KEY |
| |
| |
| |
@@ -552,17 +554,17 @@
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
<t>
- Similarly, we divide "IV" into a 128-bit initialization vector IVaes
- and a 128-bit initialization vector IVtwo:
+ Similarly, we divide "IV" into a 128-bit initialization vector
+ and a 128-bit initialization vector:
</t>
<figure anchor="figure_hkdf_ivs">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
- | AES IV (IVaes) |
+ | AES IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- | TWOFISH IV (IVtwo) |
+ | TWOFISH IV |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
@@ -571,11 +573,12 @@
<t>
The symmetric keys and IVs are used for a AES+TWOFISH combined
- cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
+ cipher. Both ciphers are used in Cipher FeedBack (CFB) mode
+ (<xref target="RFC3826" />).
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
- RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
- BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
+ RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
+ BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
]]></artwork>
<t>
The decrypted RDATA has the following format:
@@ -803,6 +806,7 @@
<back>
<references>
<name>Normative References</name>
+ <reference anchor="RFC3826"
target="https://www.rfc-editor.org/info/rfc3826";><front><title>The Advanced
Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security
Model</title><author initials="U." surname="Blumenthal" fullname="U.
Blumenthal"><organization/></author><author initials="F." surname="Maino"
fullname="F. Maino"><organization/></author><author initials="K."
surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date
year="2004" month="June" [...]
<reference anchor="RFC5890"
target="https://www.rfc-editor.org/info/rfc5890";><front><title>Internationalized
Domain Names for Applications (IDNA): Definitions and Document
Framework</title><author initials="J." surname="Klensin" fullname="J.
Klensin"><organization/></author><date year="2010"
month="August"/><abstract><t>This document is one of a collection that,
together, describe the protocol and usage context for a revision of
Internationalized Domain Names for Applications (IDNA), [...]
<reference anchor="RFC5869"
target="https://www.rfc-editor.org/info/rfc5869";>
<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: add aes reference,
gnunet <=