One document matched: draft-ietf-avt-srtp-big-aes-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3711 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
<!ENTITY rfc4568 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-avt-srtp-big-aes-04.txt">
<front>
<title abbrev="SRTP AES-192 and AES-256">
The use of AES-192 and AES-256 in Secure RTP
</title>
<author initials="D.A.M." surname="McGrew" fullname="David A. McGrew">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 525 8651</phone>
<email>mcgrew@cisco.com</email>
<uri>http://www.mindspring.com/~dmcgrew/dam.htm</uri>
</address>
</author>
<date month="September" year="2010" />
<area>General</area>
<keyword>SRTP</keyword>
<abstract><t>
This memo describes the use of the Advanced Encryption Standard (AES)
with 192 and 256 bit keys within the Secure RTP protocol. It details
Counter Mode encryption for SRTP and SRTCP and a new SRTP Key
Derivation Function (KDF) for AES-192 and AES-256.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This memo describes the use of the Advanced Encryption Standard (AES)
<xref target="FIPS197"/> with 192 and 256 bit keys within the Secure
RTP protocol <xref target="RFC3711"/>. Below those block ciphers are
referred to as AES-192 and AES-256, respectively, and the use of AES
with a 128 bit key is referred to as AES-128. This document describes
Counter Mode encryption for SRTP and SRTCP and appropriate SRTP Key
Derivation Functions for AES-192 and AES-256. It also defines new
cryptosuites that use these new functions.
</t>
<t>
While AES-128 is widely regarded as more than adequately secure, some
users may be motivated to adopt AES-192 or AES-256. One motivation is
conformance to the Suite B profile (which requires AES-256 for the
protection of TOP SECRET information) <xref target="suiteB"/>. Others
may be motivated by a perceived need to purse a highly conservative
security strategy; see <xref target="Security"/> for more discussion
of security issues.
</t>
<t>
The crypto functions described in this document are an addition to, and not
a replacement for, the crypto functions defined in <xref target="RFC3711"/>.
</t>
<section title="Conventions Used In This Document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
</section>
<section anchor="encryption" title="AES-192 and AES-256 Encryption">
<t>
Section 4.1.1 of <xref target="RFC3711"/> defines AES counter mode
encryption, which it refers to as AES_CM.
<!--
(Note that AES_CM conforms
to the NIST definition of counter mode <xref target="NISTmodes"/>,
which is designated as CTR; RFC 3711 was written prior to that
publication, though it was published afterwards.)
--> This definition applies to all of the AES key sizes. In this
note, AES-192 counter mode and AES-256 counter mode and are denoted as
AES_192_CM and AES_256_CM respectively. In both of these ciphers, the
plaintext inputs to the block cipher are formed as in AES_CM, and the
block cipher outputs are processed as in AES_CM. The only difference
in the processing is that AES_192_CM uses AES-192, and AES_256_CM uses
AES-256. Both AES_192_CM and AES_256_CM use a 112-bit salt as an
input, as does AES_CM.
</t>
<t>
For the convenience of the reader, the structure of the counter blocks
in SRTP counter mode encryption is illustrated in <xref target="CMfig"/>,
using the terminology from Section 4.1.1 of <xref target="RFC3711"/>.
In this diagram, the symbol (+) denotes the bitwise exclusive-or operation, and
the AES encrypt operation uses AES-128, AES-192, or AES-256 for
AES_CM, AES_192_CM, and AES_256_CM, respectively. The field labeled
b_c contains a block counter, the value of which increments once for
each invocation of the "AES Encrypt" function.
</t>
<!--
<t>
A keystream segment SHALL be the concatenation of the 128-bit output
blocks of the AES cipher in the encrypt direction, using key k = k_e,
in which the block indices are in increasing order. Symbolically,
each keystream segment looks like
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
where the 128-bit integer value IV SHALL be defined by the SSRC, the
SRTP packet index i, and the SRTP session salting key k_s, as below.
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
Each of the three terms in the XOR-sum above is padded with as many
leading zeros as needed to make the operation well-defined,
considered as a 128-bit value.
</t>
-->
<figure anchor="CMfig" title="AES Counter Mode. ">
<artwork>
one octet
<-->
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00| SSRC | packet index | b_c |---+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v
| salt (k_s) |00|00|->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
v
+-------------+
encryption key (k_e) -> | AES encrypt |
+-------------+
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| keystream block |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
</artwork>
</figure>
</section>
<section anchor="KDF" title="The AES_192_CM_PRF and AES_256_CM_PRF Key Derivation Functions">
<t>
Section 4.3.3 of <xref target="RFC3711"/> defines an AES counter mode
key derivation function, which it refers to as AES_CM PRF (and
sometimes as AES-CM PRF). (That specification uses the term PRF, or
pseudo-random function, interchangeably with the phrase "key
derivation function". )
<!--
(Note that AES_CM conforms
to the NIST definition of counter mode <xref target="NISTmodes"/>,
which is designated as CTR; RFC 3711 was written prior to that
publication, though it was published afterwards.)
--> This key derivation function can be used with any AES key size.
In this note, the AES-192 counter mode PRF and AES-256 counter mode
PRF are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF
respectively. In both of these PRFs, the plaintext inputs to the
block cipher are formed as in the AES_CM PRF, and the block cipher
outputs are processed as in the AES_CM PRF. The only difference in
the processing is that AES_192_CM_PRF uses AES-192, and AES_256_CM_PRF
uses AES-256. Both AES_192_CM_PRF and AES_256_CM_PRF use a 112-bit
salt as an input, as does the AES_CM PRF.
</t>
<t>
For the convenience of the reader, the structure of the counter blocks
in SRTP counter mode key derivation is illustrated in
<xref target="KDFfig"/>, using the terminology from Section 4.3.3 of
<xref target="RFC3711"/>. In this diagram, the symbol (+) denotes the
bitwise exclusive-or operation, and the "AES Encrypt" operation uses
AES-128, AES-192, or AES-256 for the AES_CM PRF, AES_192_CM_PRF, and
AES_256_CM_PRF, respectively. The field "LB" contains the 8-bit
constant "label" which is provided as an input to the key derivation
function (and which is distinct for each type of key generated by that
function). The field labeled b_c contains a block counter, the value
of which increments once for each invocation of the "AES Encrypt"
function.
</t>
<figure anchor="KDFfig" title="The AES counter mode Key Derivation Function">
<artwork>
one octet
<-->
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00|00|00|00|LB| index DIV kdr | b_c |---+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v
| master salt |00|00|->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|
v
+-------------+
master key -> | AES encrypt |
+-------------+
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| output block |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
</artwork>
</figure>
<section anchor="IV" title="Usage Requirements">
<t>
When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as
the key derivation function, and AES_128_CM MUST NOT be
used as the key derivation function.
</t>
<t>
When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as
the key derivation function. Both AES_128_CM and AES_192_CM MUST NOT
be used as the key derivation function.
</t>
<t>
<list>
<t>
Rationale: it is essential that the cryptographic strength of the key
derivation meets or exceeds that of the encryption method.
It is natural to use the same function for both encryption and
key derivation. However, it is not required to do so
because it is desirable to allow these ciphers to be used
with alternative key derivation functions that may
be defined in the future.
</t>
</list>
</t>
</section>
</section>
<section anchor="cryptosuites" title="Crypto Suites">
<t>
This section defines SRTP crypto suites that use the ciphers and key
derivation functions defined in this document. These suites are
registered with IANA for use with the SDP Security Descriptions
attributes (Section 10.3.2.1 of
<xref target="RFC4568"/>). Other SRTP key
management methods that use the crypto functions defined in this
document are encouraged to also use these crypto suite definitions.
<list>
<t>
Rationale: the crypto suites use the same authentication function that
is mandatory-to-implement in SRTP, HMAC-SHA1 with a 160 bit key.
HMAC-SHA1 would accept larger key sizes, but when it is used with keys
larger than 160 bits, it does not provide resistance to cryptanalysis
greater than that security level, because it has only 160 bits of
internal state. By retaining 160-bit authentication keys,
the crypto suites in this note have more compatibility with existing
crypto suites and implementations of them.
</t>
</list>
</t>
<texttable anchor="AES_192_CM_HMAC_SHA1_80" title="The AES_192_CM_HMAC_SHA1_80 cryptosuite.">
<ttcol align='left'> Parameter</ttcol>
<ttcol align='left'> Value</ttcol>
<c>Master key length</c> <c> 192 bits</c>
<c>Master salt length</c> <c> 112 bits</c>
<c>Key Derivation Function</c> <c> AES_192_CM_PRF (<xref target="KDF"/>)</c>
<c>Default key lifetime</c> <c> 2^31 packets</c>
<c>Cipher (for SRTP and SRTCP) </c> <c> AES_192_CM (<xref target="encryption"/>) </c>
<c>SRTP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>)</c>
<c>SRTP authentication key length </c><c> 160 bits </c>
<c>SRTP authentication tag length </c><c> 80 bits </c>
<c>SRTCP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>) </c>
<c>SRTCP authentication key length</c><c> 160 bits </c>
<c>SRTCP authentication tag length</c><c> 80 bits </c>
</texttable>
<texttable anchor="AES_192_CM_HMAC_SHA1_32" title="The AES_192_CM_HMAC_SHA1_32 cryptosuite.">
<ttcol align='left'> Parameter</ttcol>
<ttcol align='left'> Value</ttcol>
<c>Master key length</c> <c> 192 bits</c>
<c>Master salt length</c> <c> 112 bits</c>
<c>Key Derivation Function</c> <c> AES_192_CM_PRF (<xref target="KDF"/>)</c>
<c>Default key lifetime</c> <c> 2^31 packets</c>
<c>Cipher (for SRTP and SRTCP) </c> <c> AES_192_CM (<xref target="encryption"/>) </c>
<c>SRTP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>)</c>
<c>SRTP authentication key length </c><c> 160 bits </c>
<c>SRTP authentication tag length </c><c> 32 bits </c>
<c>SRTCP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>) </c>
<c>SRTCP authentication key length</c><c> 160 bits </c>
<c>SRTCP authentication tag length</c><c> 80 bits </c>
</texttable>
<texttable anchor="AES_256_CM_HMAC_SHA1_80" title="The AES_256_CM_HMAC_SHA1_80 cryptosuite.">
<ttcol align='left'> Parameter</ttcol>
<ttcol align='left'> Value</ttcol>
<c>Master key length</c> <c> 256 bits</c>
<c>Master salt length</c> <c> 112 bits</c>
<c>Key Derivation Function</c> <c> AES_256_CM_PRF (<xref target="KDF"/>)</c>
<c>Default key lifetime</c> <c> 2^31 packets</c>
<c>Cipher (for SRTP and SRTCP) </c> <c> AES_256_CM (<xref target="encryption"/>) </c>
<c>SRTP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>)</c>
<c>SRTP authentication key length </c><c> 160 bits </c>
<c>SRTP authentication tag length </c><c> 80 bits </c>
<c>SRTCP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>) </c>
<c>SRTCP authentication key length</c><c> 160 bits </c>
<c>SRTCP authentication tag length</c><c> 80 bits </c>
</texttable>
<texttable anchor="AES_256_CM_HMAC_SHA1_32" title="The AES_256_CM_HMAC_SHA1_32 cryptosuite.">
<ttcol align='left'> Parameter</ttcol>
<ttcol align='left'> Value</ttcol>
<c>Master key length</c> <c> 256 bits</c>
<c>Master salt length</c> <c> 112 bits</c>
<c>Key Derivation Function</c> <c> AES_256_CM_PRF (<xref target="KDF"/>)</c>
<c>Default key lifetime</c> <c> 2^31 packets</c>
<c>Cipher (for SRTP and SRTCP) </c> <c> AES_256_CM (<xref target="encryption"/>) </c>
<c>SRTP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>)</c>
<c>SRTP authentication key length </c><c> 160 bits </c>
<c>SRTP authentication tag length </c><c> 32 bits </c>
<c>SRTCP authentication function </c> <c> HMAC-SHA1 (Section 4.2.1 of <xref target="RFC3711"/>) </c>
<c>SRTCP authentication key length</c><c> 160 bits </c>
<c>SRTCP authentication tag length</c><c> 80 bits </c>
</texttable>
<!--
+---------------------+-------------+--------------+---------------+
| |AES_CM_128_ | AES_CM_128_ | F8_128_ |
| |HMAC_SHA1_80 | HMAC_SHA1_32 | HMAC_SHA1_80 |
+---------------------+-------------+--------------+---------------+
| Master key length | 128 bits | 128 bits | 128 bits |
| Salt value | 112 bits | 112 bits | 112 bits |
| Default lifetime | 2^31 packets| 2^31 packets | 2^31 packets |
| Cipher | AES Counter | AES Counter | F8 |
| | Mode | Mode | |
| Encryption key | 128 bits | 128 bits | 128 bits |
| MAC | HMAC-SHA1 | HMAC-SHA1 | HMAC-SHA1 |
| Authentication tag | 80 bits | 32 bits | 80 bits |
| SRTP auth. key | 160 bits | 160 bits | 160 bits |
| SRTCP auth. key | 160 bits | 160 bits | 160 bits |
+---------------------+-------------+--------------+---------------+
-->
</section>
<section anchor="iana" title="IANA Considerations">
<t>
IANA is expected to assign the following parameters for the SDP Security
Descriptions crypto suite attribute.
<list>
<t> AES_192_CM_HMAC_SHA1_80 </t>
<t> AES_192_CM_HMAC_SHA1_32 </t>
<t> AES_256_CM_HMAC_SHA1_80 </t>
<t> AES_256_CM_HMAC_SHA1_32 </t>
</list>
The cryptosuites are as defined in <xref target="cryptosuites"/>.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
AES-128 provides a level of security that is widely regarded as being
more than sufficient for providing confidentiality. It is believed
that the economic cost of breaking AES-128 is significantly higher
than the cost of more direct approaches to violating system security,
e.g. theft, bribery, wiretapping, and other forms of malfeasance.
</t>
<t>
Future advances in the state of the art of cryptanalysis could
eliminate this confidence in AES-128, and motivate the use of AES-192
or AES-256. AES-192 is regarded as being secure even against some
adversaries for which breaking AES-128 may be feasible. Similarly,
AES-256 is regarded as being secure even against some adversaries for
which it may be feasible to break AES-192. The availability
of the larger key size versions of AES provides a fallback plan
in case of unanticipated cryptanalytic results.
</t>
<t>
It is conjectured that AES-256 provides adequate security even against
adversaries that possess the ability to construct a quantum computer
that works on 256 or more quantum bits. No such computer is known to
exist; its feasibility is an area of active speculation and research.
</t>
<t>
Despite the apparent sufficiency of AES-128, some users are interested
in the larger AES key sizes. For some applications, the 40% increase
in computational cost for AES-256 over AES-128 is a worthwhile bargain
when traded for the security advantages outlined above. These
applications include those with a perceived need for very high
security, e.g. due to a desire for very long-term confidentiality.
</t>
<t>
As with any cipher, the conjectured security level of AES may change
over time. The considerations in this section reflect the best
knowledge available at the time of publication of this document.
</t>
<t>
It is desirable that AES_192_CM and AES_192_CM_PRF be used with an
authentication function that uses a 192 bit key, and that AES_256_CM
and AES_256_CM_PRF be used with an authentication function that uses a
256 bit key. However, this desire is not regarded as
security-critical. Cryptographic authentication is resilient against
future advances in cryptanalysis, since the opportunity for a forgery
attack against a session closes when that session closes. For this
reason, this note defines new ciphers, but not new authentication
functions.
</t>
</section>
<section anchor="testCases" title="Test Cases">
<t>
The test cases in this section are based on Appendix B of <xref target="RFC3711"/>.
</t>
<section title="AES-256-CM Test Cases">
<t>
<figure>
<artwork>
Keystream segment length: 1044512 octets (65282 AES blocks)
Session Key: 57f82fe3613fd170a85ec93c40b1f092
2ec4cb0dc025b58272147cc438944a98
Rollover Counter: 00000000
Sequence Number: 0000
SSRC: 00000000
Session Salt: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 (already shifted)
Offset: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000
Counter Keystream
f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 92bdd28a93c3f52511c677d08b5515a4
f0f1f2f3f4f5f6f7f8f9fafbfcfd0001 9da71b2378a854f67050756ded165bac
f0f1f2f3f4f5f6f7f8f9fafbfcfd0002 63c4868b7096d88421b563b8c94c9a31
... ...
f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff cea518c90fd91ced9cbb18c078a54711
f0f1f2f3f4f5f6f7f8f9fafbfcfdff00 3dbc4814f4da5f00a08772b63c6a046d
f0f1f2f3f4f5f6f7f8f9fafbfcfdff01 6eb246913062a16891433e97dd01a57f
</artwork>
</figure>
</t>
</section>
<section title="AES_256_CM_PRF Test Cases">
<t>
This section provides test data for the AES_256_CM_PRF key
derivation function, which uses AES-256 in Counter Mode. In the
following, we walk through the initial key derivation for the
AES-256 Counter Mode cipher, which requires a 32 octet session
encryption key and a 14 octet session salt, and the HMAC-SHA1
authentication function, which requires a 20-octet session
authentication key. These values are called the cipher key, the
cipher salt, and the auth key in the following. Since this is the
initial key derivation and the key derivation rate is equal to
zero, the value of (index DIV key_derivation_rate) is zero
(actually, a six-octet string of zeros). In the following, we
shorten key_derivation_rate to kdr.
</t>
<t>
The inputs to the key derivation function are the 32 octet master key
and the 14 octet master salt:
<figure>
<artwork>
master key: f0f04914b513f2763a1b1fa130f10e29
98f6f6e43e4309d1e622a0e332b9f1b6
master salt: 3b04803de51ee7c96423ab5b78d2
</artwork>
</figure>
We first show how the cipher key is generated. The input block for
AES-256-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption key label 0x00 with (index DIV
kdr), then padding on the right with two null octets (which
implements the multiply-by-2^16 operation, see Section 4.3.3 of RFC
3711). The resulting value is then AES-256-CM- encrypted using the
master key to get the cipher key.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 00
master salt: 3b04803de51ee7c96423ab5b78d2
-----------------------------------------------
xor: 3b04803de51ee7c96423ab5b78d2 (x, PRF input)
x*2^16: 3b04803de51ee7c96423ab5b78d20000 (AES-256-CM input)
x*2^16 + 1: 3b04803de51ee7c96423ab5b78d20001 (2nd AES input)
cipher key: 5ba1064e30ec51613cad926c5a28ef73 (1st AES output)
1ec7fb397f70a960653caf06554cd8c4 (2nd AES output)
</artwork>
</figure>
Next, we show how the cipher salt is generated. The input block for
AES-256-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption salt label. That value is padded and
encrypted as above.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 02
master salt: 3b04803de51ee7c96423ab5b78d2
----------------------------------------------
xor: 3b04803de51ee7cb6423ab5b78d2 (x, PRF input)
x*2^16: 3b04803de51ee7cb6423ab5b78d20000 (AES-256-CM input)
fa31791685ca444a9e07c6c64e93ae6b (AES-256 ouptut)
cipher salt: fa31791685ca444a9e07c6c64e93
</artwork>
</figure>
We now show how the auth key is generated. The input block for
AES-256-CM is generated as above, but using the authentication key
label.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 01
master salt: 3b04803de51ee7c96423ab5b78d2
-----------------------------------------------
xor: 3b04803de51ee7c86423ab5b78d2 (x, PRF input)
x*2^16: 3b04803de51ee7c86423ab5b78d20000 (AES-256-CM in)
Below, the AES-256 output blocks that form the auth key are shown
on the left, while the corresponding AES-256 input blocks are shown
on the right. Note that the final AES-256 output is truncated to a
four-byte length. The final auth key is shown below.
auth key blocks AES-256 input blocks
fd9c32d39ed5fbb5a9dc96b30818454d 3b04803de51ee7c86423ab5b78d20000
1313dc05 3b04803de51ee7c86423ab5b78d20001
auth key: fd9c32d39ed5fbb5a9dc96b30818454d1313dc05
</artwork>
</figure>
</t>
</section>
<section title="AES-192-CM Test Cases">
<t>
<figure>
<artwork>
Keystream segment length: 1044512 octets (65282 AES blocks)
Session Key: eab234764e517b2d3d160d587d8c8621
9740f65f99b6bcf7
Rollover Counter: 00000000
Sequence Number: 0000
SSRC: 00000000
Session Salt: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 (already shifted)
Offset: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000
Counter Keystream
f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 35096cba4610028dc1b57503804ce37c
f0f1f2f3f4f5f6f7f8f9fafbfcfd0001 5de986291dcce161d5165ec4568f5c9a
f0f1f2f3f4f5f6f7f8f9fafbfcfd0002 474a40c77894bc17180202272a4c264d
... ...
f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff d108d1a31a00bad6367ec23eb044b415
f0f1f2f3f4f5f6f7f8f9fafbfcfdff00 c8f57129fdeb970b59f917b257662d4c
f0f1f2f3f4f5f6f7f8f9fafbfcfdff01 a5dab625811034e8cebdfeb6dc158dd3
</artwork>
</figure>
</t>
</section>
<section title="AES_192_CM_PRF Test Cases">
<t>
This section provides test data for the AES_192_CM_PRF key
derivation function, which uses AES-192 in Counter Mode. In the
following, we walk through the initial key derivation for the
AES-192 Counter Mode cipher, which requires a 24 octet session
encryption key and a 14 octet session salt, and the HMAC-SHA1
authentication function, which requires a 20-octet session
authentication key. These values are called the cipher key, the
cipher salt, and the auth key in the following. Since this is the
initial key derivation and the key derivation rate is equal to
zero, the value of (index DIV key_derivation_rate) is zero
(actually, a six-octet string of zeros). In the following, we
shorten key_derivation_rate to kdr.
</t>
<t>
The inputs to the key derivation function are the 24 octet master key
and the 14 octet master salt:
<figure>
<artwork>
master key: 73edc66c4fa15776fb57f9505c171365
50ffda71f3e8e5f1
master salt: c8522f3acd4ce86d5add78edbb11
</artwork>
</figure>
We first show how the cipher key is generated. The input block for
AES-192-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption key label 0x00 with (index DIV
kdr), then padding on the right with two null octets (which
implements the multiply-by-2^16 operation, see Section 4.3.3 of RFC
3711). The resulting value is then AES-192-CM encrypted using the
master key to get the cipher key.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 00
master salt: c8522f3acd4ce86d5add78edbb11
-----------------------------------------------
xor: c8522f3acd4ce86d5add78edbb11 (x, PRF input)
x*2^16: c8522f3acd4ce86d5add78edbb110000 (AES-192-CM input)
x*2^16 + 1: c8522f3acd4ce86d5add78edbb110001 (2nd AES input)
cipher key: 31874736a8f1143870c26e4857d8a5b2 (1st AES output)
c4a354407faadabb (2nd AES output)
</artwork>
</figure>
Next, we show how the cipher salt is generated. The input block for
AES-192-CM is generated by exclusive-oring the master salt with the
concatenation of the encryption salt label. That value is padded and
encrypted as above.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 02
master salt: c8522f3acd4ce86d5add78edbb11
----------------------------------------------
xor: c8522f3acd4ce86f5add78edbb11 (x, PRF input)
x*2^16: c8522f3acd4ce86f5add78edbb110000 (AES-192-CM input)
2372b82d639b6d8503a47adc0a6c2590 (AES-192 ouptut)
cipher salt: 2372b82d639b6d8503a47adc0a6c
</artwork>
</figure>
We now show how the auth key is generated. The input block for
AES-192-CM is generated as above, but using the authentication key
label.
<figure>
<artwork>
index DIV kdr: 000000000000
label: 01
master salt: c8522f3acd4ce86d5add78edbb11
-----------------------------------------------
xor: c8522f3acd4ce86c5add78edbb11 (x, PRF input)
x*2^16: c8522f3acd4ce86c5add78edbb110000 (AES-192-CM in)
Below, the AES-192 output blocks that form the auth key are shown
on the left, while the corresponding AES-192 input blocks are shown
on the right. Note that the final AES-192 output is truncated to a
four-byte length. The final auth key is shown below.
auth key blocks AES-192 input blocks
355b10973cd95b9eacf4061c7e1a7151 c8522f3acd4ce86c5add78edbb110000
e7cfbfcb c8522f3acd4ce86c5add78edbb110001
auth key: 355b10973cd95b9eacf4061c7e1a7151e7cfbfcb
</artwork>
</figure>
</t>
</section>
</section>
<!--
<section anchor="questions" title="Open Questions">
<t>
It may be desirable to eliminate AES-192 altogether, leaving users
with the simpler choice of using AES-128 or AES-256. This option
preserves the possibility of Suite B conformance. Given that the
incremental computational cost of AES-256 over AES-192 is only
16%, and the additional key storage overhead is only 33%,
this option imposes only a minimal burden on implementations.
</t>
-->
<!--
<t>
It may be desirable to use AES in the Chained Message Authentication
Code (CMAC) mode of operation <xref target="CMAC"/> in conjunction
with the ciphers defined in this document, with the CMAC key size
matching the counter mode key size. This mode of operation can be
used as a replacement for HMAC-SHA1, and that use would provide an
authentication function with security that is directly comparable to
AES-192 and AES-256. This mode of operation has some additional
benefits and may be worth considering for secure RTP.
</t>
</section>
-->
<section title="Acknowledgements">
<t>
Thanks are due to John Mattsson for verifying the test cases in the
document and providing comments, and to Bob Bell for feedback and
encouragement.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<reference anchor="FIPS197">
<front>
<title>The Advanced Encryption Standard (AES)</title>
<author fullname="U.S. National Institute of Standards and Technology (NIST)">
<organization/>
</author>
</front>
<seriesInfo name="FIPS-197" value="Federal Information
Processing Standard" />
</reference>
&rfc3711;
&rfc4568;
<!-- &I-D.ietf-mmusic-sdescriptions; -->
</references>
<references title="Informative References">
<reference anchor="suiteB">
<front>
<title>Suite B Cryptography</title>
<author fullname="U. S. National Security Agency (NSA)">
<organization/>
</author>
</front>
<seriesInfo name="" value="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml" />
</reference>
<!--
<reference anchor="CMAC">
<front>
<title>NIST Special Publication 800-38B</title>
<author fullname="M. Dworkin, U.S. National Institute of Standards and Technology (NIST))">
<organization/>
</author>
</front>
<seriesInfo name="" value="http://csrc.nist.gov/CryptoToolkit/modes/800-38_Series_Publications/SP800-38B.pdf" />
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:19:03 |