commit 165710199fc5890714136cc7886f16251b4d78a2
parent 06acd7036491922701b917f0ede5a2f77a5323f1
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 16:00:49 +0200
add aes reference
Diffstat:
3 files changed, 82 insertions(+), 72 deletions(-)
diff --git 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/info/rfc3826</a>></span>. </dd>
<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
@@ -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: schanzen@gnunet.org
-
@@ -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: schanzen@gnunet.org
+
+
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
@@ -886,11 +893,4 @@ Internet-Draft The GNU Name System July 2019
-
-
-
-
-
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 16]
diff --git 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"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
<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), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
<front>
