RFC 8269

The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)

πŸ“… published October 2017, from ietf

RFC 8269: The ARIA Algorithm and Its Use with SRTP πŸ’–

okay bestie, this one is all about ARIA, a block cipher, and how to use it inside SRTP so calls and streams stay private πŸ”βœ¨ here's the official info:

  • RFC: 8269 πŸŽ€
  • Title: The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
  • Authors: W. Kim, J. Lee, J. Park, D. Kwon (NSRI), and D. Kim (Kookmin Univ.)
  • Category: Informational πŸ¦‹
  • ISSN: 2070-1721
  • Date: October 2017
  • Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates 🌸

Abstract ✨

this doc defines how to use the ARIA block cipher in SRTP πŸ”₯ it covers two modes (CTR and GCM), the SRTP key derivation functions for ARIA, and also DTLS-SRTP protection profiles and MIKEY parameter sets for ARIA too πŸ’…

Status of This Memo πŸ“Œ

this one is not an Internet Standards Track spec. it's published for informational purposes πŸ“

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full picture 🧚

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8269 πŸ’œ

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were in effect on the date of publication. please read these carefully, because they explain your rights and restrictions for this doc πŸ“œ

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as described in the Simplified BSD License 🫢

Table of Contents πŸ—‚οΈ

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  ARIA  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Cryptographic Transforms  . . . . . . . . . . . . . . . . . .   3
  2.1.  ARIA-CTR  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.2.  ARIA-GCM  . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Key Derivation Functions  . . . . . . . . . . . . . . . . . .   4
4.  Protection Profiles . . . . . . . . . . . . . . . . . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
  6.1.  DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . .   8
  6.2.  MIKEY . . . . . . . . . . . . . . . . . . . . . . . . . .   8
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  12
  A.1.  ARIA-CTR Test Vectors . . . . . . . . . . . . . . . . . .  12
    A.1.1.  SRTP_ARIA_128_CTR_HMAC_SHA1_80  . . . . . . . . . . .  12
    A.1.2.  SRTP_ARIA_256_CTR_HMAC_SHA1_80  . . . . . . . . . . .  13
  A.2.  ARIA-GCM Test Vectors . . . . . . . . . . . . . . . . . .  14
    A.2.1.  SRTP_AEAD_ARIA_128_GCM  . . . . . . . . . . . . . . .  14
    A.2.2.  SRTP_AEAD_ARIA_256_GCM  . . . . . . . . . . . . . . .  15
  A.3.  Key Derivation Test Vectors . . . . . . . . . . . . . . .  15
    A.3.1.  ARIA_128_CTR_PRF  . . . . . . . . . . . . . . . . . .  15
    A.3.2.  ARIA_256_CTR_PRF  . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

this doc defines how to use the ARIA block cipher [RFC5794] inside the Secure Real-time Transport Protocol (SRTP) [RFC3711] πŸ¦‹ the goal is confidentiality for Real-time Transport Protocol (RTP) [RFC3550] traffic and for RTP Control Protocol (RTCP) [RFC3550] traffic too πŸ”

1.1. ARIA πŸ‡°πŸ‡·

ARIA is a general-purpose block cipher that Korean cryptographers developed in 2003 πŸ’– it's an iterated block cipher with 128-, 192-, and 256-bit keys. it encrypts 128-bit blocks in 12, 14, or 16 rounds, depending on key size πŸ”₯ it's secure and works well on most software and hardware, including 32-bit and 8-bit processors πŸ’…

it became a Korean standard block cipher algorithm in 2004 [ARIAKS] and has been widely used in Korea, especially for government-to-public services 🌸 it was added to Public-Key Cryptography Standards (PKCS) #11 in 2007 [ARIAPKCS] ✨ the algorithm spec and object identifiers are in [RFC5794] 🧚

1.2. Terminology πŸ“–

so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in BCP 14 [RFC2119] [RFC8174]. they only count when they appear in all capitals, as shown here πŸŽ€ that's the rule, so watch your caps lock πŸ™ˆ

2. Cryptographic Transforms πŸ”₯

block ciphers ARIA and AES have a lot in common: mode, key size, and block size πŸ’œ ARIA has no restrictions on which modes of operation it can be used with 🌈 so this doc defines two ways to run ARIA inside SRTP: (1) ARIA in Counter Mode (ARIA-CTR), and (2) ARIA in Galois/Counter Mode (ARIA-GCM) πŸ‘‘

2.1. ARIA-CTR πŸ“

Section 4.1.1 of [RFC3711] defines AES-128 counter mode encryption, which it calls "AES_CM" ✨ Section 2 of [RFC6188] defines "AES_256_CM" in SRTP πŸ’… ARIA counter modes work the same way, except every AES invocation gets swapped for ARIA [RFC5794]. they're called ARIA_128_CTR and ARIA_256_CTR, depending on key length πŸ¦‹

the plaintext inputs to the block cipher are formed just like AES-CTR (AES_CM, AES_256_CM), and the block cipher outputs get processed like AES-CTR too 🫢 and this is the big one: ARIA-CTR MUST be used only in conjunction with an authentication transform 🚨

⚠️ ARIA-CTR MUST be used only together with an authentication transform. no skipping this part bestie πŸ’€

Section 3.2 of [RFC6904] defines AES-CTR for SRTP header extension keystream generation 🧚 when ARIA-CTR is used, the header extension keystream SHALL be generated the same way, except every AES invocation gets replaced by ARIA [RFC5794] 🌸

2.2. ARIA-GCM πŸ’–

Galois/Counter Mode [GCM] [RFC5116] is an Authenticated Encryption with Associated Data (AEAD) block cipher mode πŸ” the ARIA-GCM description is basically the same as AES-GCM in [RFC5116] and [RFC5282] ✨

[RFC7714] describes how AES-GCM is used with SRTP πŸŽ€ ARIA-GCM with SRTP is defined the same way, except each AES invocation is replaced by ARIA [RFC5794] πŸ’… when header extension encryption [RFC6904] is in use, a separate keystream to encrypt the selected RTP header extension elements MUST be generated the same way [RFC7714] describes, except AES-CTR gets swapped for ARIA-CTR πŸ‘‘

3. Key Derivation Functions πŸ”‘

Section 4.3.3 of [RFC3711] defines the AES-128 counter mode key derivation function, which it calls "AES-CM PRF" 🌈 Section 3 of [RFC6188] defines the AES-256 counter mode key derivation function, which it calls "AES_256_CM_PRF" πŸ“ the ARIA-CTR Pseudorandom Function (PRF) works the same way, except each AES invocation is replaced by ARIA πŸ¦‹

depending on the underlying encryption key length, the ARIA-CTR PRFs are called "ARIA_128_CTR_PRF" and "ARIA_256_CTR_PRF" 🧚 the usage requirements in [RFC6188] and [RFC7714] for the AES-CM PRF apply to the ARIA-CTR PRF too πŸ’œ

4. Protection Profiles ✨

okay bestie, this is where we pick our outfits πŸ‘— This section defines the SRTP protection profiles that use the ARIA transforms and key derivation functions from this doc. The list below shows the SRTP transform parameters for each profile, and they're written for use with DTLS-SRTP [RFC5764] πŸŽ€

The parameters cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length are all counted in bits. maximum_lifetime is the max number of packets that can be protected with each single set of keys while that profile is in use πŸ”‘ All of these apply to both RTP and RTCP, unless the RTCP parameters are listed separately.

   SRTP_ARIA_128_CTR_HMAC_SHA1_80
           cipher:                   ARIA_128_CTR
           cipher_key_length:        128 bits
           cipher_salt_length:       112 bits
           key derivation function:  ARIA_128_CTR_PRF
           auth_function:            HMAC-SHA1
           auth_key_length:          160 bits
           auth_tag_length:          80 bits
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

   SRTP_ARIA_128_CTR_HMAC_SHA1_32
           cipher:                   ARIA_128_CTR
           cipher_key_length:        128 bits
           cipher_salt_length:       112 bits
           key derivation function:  ARIA_128_CTR_PRF
           auth_function:            HMAC-SHA1
           auth_key_length:          160 bits
           SRTP auth_tag_length:     32 bits
           SRTCP auth_tag_length:    80 bits
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

   SRTP_ARIA_256_CTR_HMAC_SHA1_80
           cipher:                   ARIA_256_CTR
           cipher_key_length:        256 bits
           cipher_salt_length:       112 bits
           key derivation function:  ARIA_256_CTR_PRF
           auth_function:            HMAC-SHA1
           auth_key_length:          160 bits
           auth_tag_length:          80 bits
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

   SRTP_ARIA_256_CTR_HMAC_SHA1_32
           cipher:                   ARIA_256_CTR
           cipher_key_length:        256 bits
           cipher_salt_length:       112 bits
           key derivation function:  ARIA_256_CTR_PRF
           auth_function:            HMAC-SHA1
           auth_key_length:          160 bits
           SRTP auth_tag_length:     32 bits
           SRTCP auth_tag_length:    80 bits
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

   SRTP_AEAD_ARIA_128_GCM
           cipher:                   ARIA_128_GCM
           cipher_key_length:        128 bits
           cipher_salt_length:       96 bits
           aead_auth_tag_length:     128 bits
           auth_function:            NULL
           auth_key_length:          N/A
           auth_tag_length:          N/A
           key derivation function:  ARIA_128_CTR_PRF
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

   SRTP_AEAD_ARIA_256_GCM
           cipher:                   ARIA_256_GCM
           cipher_key_length:        256 bits
           cipher_salt_length:       96 bits
           aead_auth_tag_length:     128 bits
           auth_function:            NULL
           auth_key_length:          N/A
           auth_tag_length:          N/A
           key derivation function:  ARIA_256_CTR_PRF
           maximum_lifetime:         at most 2^31 SRTCP packets and
                                     at most 2^48 SRTP packets

The ARIA-CTR protection profiles use the same authentication transform that is mandatory to implement in SRTP: HMAC-SHA1 with a 160-bit key πŸ”

Heads up, babe: the AEAD profiles don't list an auth_function, auth_key_length, or auth_tag_length, since they don't use a separate auth function, key, or tag. aead_auth_tag_length is the name used to make it super clear that this is the tag the AEAD algorithm provides, and that this tag is NOT sitting in the authentication tag field that SRTP/SRTCP gives you πŸ™ƒ

The PRFs for the ARIA profiles are defined by the ARIA-CTR PRF with the same key length as the encryption algorithm (see Section 2) ✨ SRTP_ARIA_128_CTR_HMAC and SRTP_AEAD_ARIA_128_GCM MUST use the ARIA_128_CTR_PRF key derivation function. And SRTP_ARIA_256_CTR_HMAC and SRTP_AEAD_ARIA_256_GCM MUST use the ARIA_256_CTR_PRF key derivation function. No skipping, it's giving strict πŸ’…

MIKEY defines the SRTP protection profile separately from the key length (which comes from the session encryption key length) and the authentication tag length 🧚 So the DTLS-SRTP [RFC5764] profiles get mapped to MIKEY parameter sets like this:

                              +--------------------------------------+
                              | Encryption | Encryption | Auth.      |
                              | Algorithm  | Key Length | Tag Length |
                              +======================================+
    SRTP_ARIA_128_CTR_HMAC_80 |  ARIA-CTR  | 16 octets  | 10 octets  |
    SRTP_ARIA_128_CTR_HMAC_32 |  ARIA-CTR  | 16 octets  |  4 octets  |
    SRTP_ARIA_256_CTR_HMAC_80 |  ARIA-CTR  | 32 octets  | 10 octets  |
    SRTP_ARIA_256_CTR_HMAC_32 |  ARIA-CTR  | 32 octets  |  4 octets  |
                              +======================================+

       Figure 1: Mapping MIKEY Parameters to ARIA-CTR with the HMAC
                                 Algorithm

                              +--------------------------------------+
                              | Encryption | Encryption | AEAD Auth. |
                              | Algorithm  | Key Length | Tag Length |
                              +======================================+
       SRTP_AEAD_ARIA_128_GCM |  ARIA-GCM  | 16 octets  | 16 octets  |
       SRTP_AEAD_ARIA_256_GCM |  ARIA-GCM  | 32 octets  | 16 octets  |
                              +======================================+

       Figure 2: Mapping MIKEY Parameters to the ARIA-GCM Algorithm

5. Security Considerations πŸ›‘οΈ

okay this part is SERIOUS, so read it with your whole brain 🧠 At the time this document was published, no security problem had been found on ARIA. The previous security analysis results are summarized in [ATY] πŸ“š

The security considerations in [GCM], [RFC3711], [RFC5116], [RFC6188], [RFC6904], and [RFC7714] apply to this document too, so don't skip those πŸ™ˆ This document includes crypto suites with authentication tags shorter than 80 bits. These suites MAY be used in certain application contexts where longer authentication tags may be undesirable, for example, the ones mentioned in [RFC3711], Section 7.5 ✨

Dramatic but true: otherwise, short authentication tags SHOULD NOT be used, because they may reduce authentication strength 😭 For a breakdown of the risks around weak authentication in SRTP, check out [RFC3711], Section 9.5. Do not sleep on this one πŸ’€

At the time of publication, SRTP recommends HMAC-SHA1 as the default and mandatory-to-implement MAC algorithm πŸ” Every currently registered SRTP crypto suite, except the GCM-based ones, uses HMAC-SHA1 as its HMAC algorithm for message authentication. Due to security concerns with SHA-1 [RFC6194], the IETF is gradually moving away from SHA-1 and toward stronger hash algorithms such as the SHA-2 or SHA-3 families 🌈 For SRTP, though, SHA-1 is only used in the calculation of an HMAC, and no security issue is known for that usage at the time of this publication. Phew 🫢


6. IANA Considerations πŸ“‹

6.1. DTLS-SRTP πŸŽ€

DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP protection profile". So that the algorithms in this document can be used in DTLS-SRTP, IANA added the protection profiles below to the "DTLS-SRTP Protection Profiles" registry (see <http://www.iana.org/assignments/srtp-protection/>) that was created by [RFC5764] πŸ’…

   SRTP_ARIA_128_CTR_HMAC_SHA1_80 = {0x00, 0x0B}
   SRTP_ARIA_128_CTR_HMAC_SHA1_32 = {0x00, 0x0C}
   SRTP_ARIA_256_CTR_HMAC_SHA1_80 = {0x00, 0x0D}
   SRTP_ARIA_256_CTR_HMAC_SHA1_32 = {0x00, 0x0E}
   SRTP_AEAD_ARIA_128_GCM = {0x00, 0x0F}
   SRTP_AEAD_ARIA_256_GCM = {0x00, 0x10}

6.2. MIKEY 🧚

[RFC3830] and [RFC5748] define encryption algorithms and PRFs for the SRTP policy in MIKEY πŸ“– So that the algorithms in this document can be used in MIKEY, IANA updated the "Multimedia Internet KEYing (MIKEY) Payload Name Spaces" registry (see <http://www.iana.org/assignments/mikey-payloads/>.) IANA registered the following two encryption algorithms in the "Encryption algorithm (Value 0)" subregistry within the "MIKEY Security Protocol Parameters" registry 🌸

                     +---------------+-------+
                     | SRTP encr alg | Value |
                     +---------------+-------+
                     |    ARIA-CTR   |   7   |
                     |    ARIA-GCM   |   8   |
                     +---------------+-------+

The default session encryption key length is 16 octets πŸ“

IANA also registered the following PRF in the "SRTP Pseudo Random Function (Value 5)" subregistry within the "MIKEY Security Protocol Parameters" registry πŸ‘‘

                       +----------+-------+
                       | SRTP PRF | Value |
                       +----------+-------+
                       | ARIA-CTR |   2   |
                       +----------+-------+

7. References ✨

7.1. Normative References πŸ“šβœ¨

Okay bestie, these are the must-read sources the spec leans on, so they're "normative" πŸ’…


7.2. Informative References 🧠🌸

These ones are the extra reading. Helpful, not required, but I'd still read them πŸ€“

  • [ARIAKS] Korean Agency for Technology and Standards, "128 bit block encryption algorithm ARIA - Part 1: General (in Korean)", KS X 1213-1:2014, December 2014.
  • [ARIAPKCS] RSA Laboratories, "Additional PKCS #11 Mechanisms", PKCS #11 v2.20, Amendment 3, Revision 1, January 2007.
  • [ATY] Abdelkhalek, A., Tolba, M., and A. Youssef, "Improved Linear Cryptanalysis of Round-Reduced ARIA", Information Security - ISC 2016, Lecture Notes in Computer Science (LNCS), Vol. 9866, pp. 18-34, DOI 10.1007/978-3-319-45871-7_2, September 2016.
  • [RFC5748] Yoon, S., Jeong, J., Kim, H., Jeong, H., and Y. Won, "IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)", RFC 5748, DOI 10.17487/RFC5748, August 2010, https://www.rfc-editor.org/info/rfc5748.
  • [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, https://www.rfc-editor.org/info/rfc6194.

Appendix A. Test Vectors πŸ§ͺπŸ’œ

Everything in here is hexadecimal and written in network order, which is also called big endian. These are the reference values you can check your own implementation against, so no vibes-only guessing allowed πŸ”₯

A.1. ARIA-CTR Test Vectors πŸ¦‹

Here are the shared values for the ARIA-CTR vectors, laid out like this:

Rollover Counter:          00000000
Sequence Number:           315e
SSRC:                      20e8f5eb
Authentication Key:        f93563311b354748c978913795530631
                           16452309
Session Salt:              cd3a7c42c671e0067a2a2639b43a
Initialization Vector:     cd3a7c42e69915ed7a2a263985640000
RTP Header:                8008315ebf2e6fe020e8f5eb
RTP Payload:               f57af5fd4ae19562976ec57a5a7ad55a
                           5af5c5e5c5fdf5c55ad57a4a7272d572
                           62e9729566ed66e97ac54a4a5a7ad5e1
                           5ae5fdd5fd5ac5d56ae56ad5c572d54a
                           e54ac55a956afd6aed5a4ac562957a95
                           16991691d572fd14e97ae962ed7a9f4a
                           955af572e162f57a956666e17ae1f54a
                           95f566d54a66e16e4afd6a9f7ae1c5c5
                           5ae5d56afde916c5e94a6ec56695e14a
                           fde1148416e94ad57ac5146ed59d1cc5

Note:
SSRC = Synchronization Source

A.1.1. SRTP_ARIA_128_CTR_HMAC_SHA1_80 πŸ’–

Here's the 128-bit vector, with the session key, the encrypted payload, the authenticated portion with the rollover counter tacked on, and the tag:

Session Key:               0c5ffd37a11edc42c325287fc0604f2e

Encrypted RTP Payload:     1bf753f412e6f35058cc398dc851aae3
                           a6ccdcb463fbed9cfb3de2fb76fdffa9
                           e481f5efb64c92487f59dabbc7cc72da
                           092485f3fbad87888820b86037311fa4
                           4330e18a59a1e1338ba2c21458493a57
                           463475c54691f91cec785429119e0dfc
                           d9048f90e07fecd50b528e8c62ee6e71
                           445de5d7f659405135aff3604c2ca4ff
                           4aaca40809cb9eee42cc4ad232307570
                           81ca289f2851d3315e9568b501fdce6d

Authenticated Portion || Rollover Counter:
                           8008315ebf2e6fe020e8f5eb1bf753f4
                           12e6f35058cc398dc851aae3a6ccdcb4
                           63fbed9cfb3de2fb76fdffa9e481f5ef
                           b64c92487f59dabbc7cc72da092485f3
                           fbad87888820b86037311fa44330e18a
                           59a1e1338ba2c21458493a57463475c5
                           4691f91cec785429119e0dfcd9048f90
                           e07fecd50b528e8c62ee6e71445de5d7
                           f659405135aff3604c2ca4ff4aaca408
                           09cb9eee42cc4ad23230757081ca289f
                           2851d3315e9568b501fdce6d00000000

Authentication Tag:        f9de4e729054672b0e35

A.1.2. SRTP_ARIA_256_CTR_HMAC_SHA1_80 πŸ‘‘

Same vibe, but with the 256-bit session key, so it's bigger and somehow even more iconic:

Session Key:               0c5ffd37a11edc42c325287fc0604f2e
                           3e8cd5671a00fe3216aa5eb105783b54

Encrypted RTP Payload:     c424c59fd5696305e5b13d8e8ca76566
                           17ccd7471088af9debf07b55c750f804
                           a5ac2b737be48140958a9b420524112a
                           e72e4da5bca59d2b1019ddd7dbdc30b4
                           3d5f046152ced40947d62d2c93e7b8e5
                           0f02db2b6b61b010e4c1566884de1fa9
                           702cdf8157e8aedfe3dd77c76bb50c25
                           ae4d624615c15acfdeeb5f79482aaa01
                           d3e4c05eb601eca2bd10518e9d46b021
                           16359232e9eac0fabd05235dd09e6dea

Authenticated Portion || Rollover Counter:
                           8008315ebf2e6fe020e8f5ebc424c59f
                           d5696305e5b13d8e8ca7656617ccd747
                           1088af9debf07b55c750f804a5ac2b73
                           7be48140958a9b420524112ae72e4da5
                           bca59d2b1019ddd7dbdc30b43d5f0461
                           52ced40947d62d2c93e7b8e50f02db2b
                           6b61b010e4c1566884de1fa9702cdf81
                           57e8aedfe3dd77c76bb50c25ae4d6246
                           15c15acfdeeb5f79482aaa01d3e4c05e
                           b601eca2bd10518e9d46b02116359232
                           e9eac0fabd05235dd09e6dea00000000

Authentication Tag:        192f515fab04bbb4e62c

A.2. ARIA-GCM Test Vectors 🌈

These ones use GCM, so the common values look a little different. Here's the shared setup:

Rollover Counter:          00000000
Sequence Number:           315e
SSRC:                      20e8f5eb
Encryption Salt:           000000000000000000000000

Initialization Vector:     000020e8f5eb00000000315e
RTP Payload:               f57af5fd4ae19562976ec57a5a7ad55a
                           5af5c5e5c5fdf5c55ad57a4a7272d572
                           62e9729566ed66e97ac54a4a5a7ad5e1
                           5ae5fdd5fd5ac5d56ae56ad5c572d54a
                           e54ac55a956afd6aed5a4ac562957a95
                           16991691d572fd14e97ae962ed7a9f4a
                           955af572e162f57a956666e17ae1f54a
                           95f566d54a66e16e4afd6a9f7ae1c5c5
                           5ae5d56afde916c5e94a6ec56695e14a
                           fde1148416e94ad57ac5146ed59d1cc5
Associated Data:           8008315ebf2e6fe020e8f5eb

The encrypted RTP payload is exactly 16 octets longer than the RTP payload, which is the GCM authentication tag length, so keep an eye on that length πŸ‘€

A.2.1. SRTP_AEAD_ARIA_128_GCM πŸ“

Here's the 128-bit key and the encrypted payload for this one:

Key:                       e91e5e75da65554a48181f3846349562

Encrypted RTP Payload:     4d8a9a0675550c704b17d8c9ddc81a5c
                           d6f7da34f2fe1b3db7cb3dfb9697102e
                           a0f3c1fc2dbc873d44bceeae8e444297
                           4ba21ff6789d3272613fb9631a7cf3f1
                           4bacbeb421633a90ffbe58c2fa6bdca5
                           34f10d0de0502ce1d531b6336e588782
                           78531e5c22bc6c85bbd784d78d9e680a
                           a19031aaf89101d669d7a3965c1f7e16
                           229d7463e0535f4e253f5d18187d40b8
                           ae0f564bd970b5e7e2adfb211e89a953
                           5abace3f37f5a736f4be984bbffbedc1

A.2.2. SRTP_AEAD_ARIA_256_GCM 🧚

And finally the 256-bit version, with its own key and encrypted payload:

Key:                       0c5ffd37a11edc42c325287fc0604f2e
                           3e8cd5671a00fe3216aa5eb105783b54

Encrypted RTP Payload:     6f9e4bcbc8c85fc0128fb1e4a0a20cb9
                           932ff74581f54fc013dd054b19f99371
                           425b352d97d3f337b90b63d1b082adee
                           ea9d2d7391897d591b985e55fb50cb53
                           50cf7d38dc27dda127c078a149c8eb98
                           083d66363a46e3726af217d3a00275ad
                           5bf772c7610ea4c23006878f0ee69a83
                           97703169a419303f40b72e4573714d19
                           e2697df61e7c7252e5abc6bade876ac4
                           961bfac4d5e867afca351a48aed52822
                           e210d6ced2cf430ff841472915e7ef48

A.3. Key Derivation Test Vectors ✨

okay bestie, this part is all about the key derivation test vectors πŸ”‘πŸ¦‹ they show how ARIA in Counter Mode turns one master key into the keys you actually use. we're talking a 16/24/32-octet session encryption key (the length depends on which one you pick), a 14-octet session salt, and an auth function that needs a 94-octet session authentication key. the RFC calls those the cipher key, the cipher salt, and the auth key, so that's what we'll call them too πŸ’…

the wild part? these were built the same way as the key derivation test vectors in [RFC3711] and [RFC6188]. the only change is that every AES call got swapped out for an ARIA call. so if you already know the AES version, you already know the logic 🧠✨

A.3.1. ARIA_128_CTR_PRF 🌸

so for this one, the inputs are a 16-octet master key and a 14-octet master salt πŸ”

  master key:  e1f97a0d3e018be0d64fa32c06de4139
  master salt: 0ec675ad498afeebb6960b3aabe6

  index DIV kdr:                 000000000000
  label:                       00
  master salt:   0ec675ad498afeebb6960b3aabe6
  -----------------------------------------------
  xor:           0ec675ad498afeebb6960b3aabe6     (x, PRF input)

  x*2^16:        0ec675ad498afeebb6960b3aabe60000 (ARIA-CTR input)

  cipher key:    dbd85a3c4d9219b3e81f7d942e299de4 (ARIA-CTR output)

quick heads up, the ARIA-CTR profile wants a 14-octet cipher salt, but the ARIA-GCM profile only wants 12 octets. so the next block derives the salt, and you can see both profile versions at the bottom πŸŽ€

  index DIV kdr:                 000000000000
  label:                       02
  master salt:   0ec675ad498afeebb6960b3aabe6
  ----------------------------------------------
  xor:           0ec675ad498afee9b6960b3aabe6     (x, PRF input)

  x*2^16:        0ec675ad498afee9b6960b3aabe60000 (ARIA-CTR input)

                 9700657f5f34161830d7d85f5dc8be7f (ARIA-CTR output)

  cipher salt:   9700657f5f34161830d7d85f5dc8     (ARIA-CTR profile)
                 9700657f5f34161830d7d85f         (ARIA-GCM profile)

then the auth key. this one's a longer run, so the setup block comes first 🧚

  index DIV kdr:                 000000000000
  label:                       01
  master salt:   0ec675ad498afeebb6960b3aabe6
  -----------------------------------------------
  xor:           0ec675ad498afeeab6960b3aabe6     (x, PRF input)

  x*2^16:        0ec675ad498afeeab6960b3aabe60000 (ARIA-CTR input)

and here's the good stuff: the auth key is on the left, and the ARIA input blocks that produce it are on the right πŸ‘‘

  auth key                          ARIA input blocks

  d021877bd3eaf92d581ed70ddc050e03  0ec675ad498afeeab6960b3aabe60000
  f11257032676f2a29f57b21abd3a1423  0ec675ad498afeeab6960b3aabe60001
  769749bdc5dd9ca5b43ca6b6c1f3a7de  0ec675ad498afeeab6960b3aabe60002
  4047904bcf811f601cc03eaa5d7af6db  0ec675ad498afeeab6960b3aabe60003
  9f88efa2e51ca832fc2a15b126fa7be2  0ec675ad498afeeab6960b3aabe60004
  469af896acb1852c31d822c45799      0ec675ad498afeeab6960b3aabe60005

A.3.2. ARIA_256_CTR_PRF πŸ¦‹

this one's the 256-bit version, so the master key is 32 octets and the master salt is still 14 octets πŸ”πŸ’–

  master key:  0c5ffd37a11edc42c325287fc0604f2e
               3e8cd5671a00fe3216aa5eb105783b54
  master salt: 0ec675ad498afeebb6960b3aabe6

  index DIV kdr:               000000000000
  label:                     00
  master salt: 0ec675ad498afeebb6960b3aabe6
  -----------------------------------------------
  xor:         0ec675ad498afeebb6960b3aabe6     (x, PRF input)

  x*2^16:      0ec675ad498afeebb6960b3aabe60000 (ARIA-CTR input)

  cipher key:  0649a09d93755fe9c2b2efba1cce930a (ARIA-CTR 1st output)
               f2e76ce8b77e4b175950321aa94b0cf4 (ARIA-CTR 2nd output)

same deal with the salt: ARIA-CTR takes 14 octets, ARIA-GCM takes 12 🫢

  index DIV kdr:                000000000000
  label:                      02
  master salt:  0ec675ad498afeebb6960b3aabe6
  ----------------------------------------------
  xor:          0ec675ad498afee9b6960b3aabe6     (x, PRF input)

  x*2^16:       0ec675ad498afee9b6960b3aabe60000 (ARIA-CTR input)

                194abaa8553a8eba8a413a340fc80a3d (ARIA-CTR output)

  cipher salt:  194abaa8553a8eba8a413a340fc8     (ARIA-CTR profile)
                194abaa8553a8eba8a413a34         (ARIA-GCM profile)

and the auth key setup 🧚

  index DIV kdr:                000000000000
  label:                      01
  master salt:  0ec675ad498afeebb6960b3aabe6
  -----------------------------------------------
  xor:          0ec675ad498afeeab6960b3aabe6     (x, PRF input)

  x*2^16:       0ec675ad498afeeab6960b3aabe60000 (ARIA-CTR input)

last one: the auth key on the left, the input blocks on the right, same as before 🌈

  auth key                           ARIA input blocks

  e58d42915873b71899234807334658f2   0ec675ad498afeeab6960b3aabe60000
  0bc460181d06e02b7a9e60f02ff10bfc   0ec675ad498afeeab6960b3aabe60001
  9ade3795cf78f3e0f2556d9d913470c4   0ec675ad498afeeab6960b3aabe60002
  e82e45d254bfb8e2933851a3930ffe7d   0ec675ad498afeeab6960b3aabe60003
  fca751c03ec1e77e35e28dac4f17d1a5   0ec675ad498afeeab6960b3aabe60004
  80bdac028766d3b1e8f5a41faa3c       0ec675ad498afeeab6960b3aabe60005

Authors' Addresses πŸŽ€

these are the people who wrote it, so go give them some love 🫢

Woo-Hwan Kim
National Security Research Institute
P.O. Box 1, Yuseong
Daejeon  34188
Korea

Email: whkim5@nsr.re.kr


Jungkeun Lee
National Security Research Institute
P.O. Box 1, Yuseong
Daejeon  34188
Korea

Email: jklee@nsr.re.kr


Je-Hong Park
National Security Research Institute
P.O. Box 1, Yuseong
Daejeon  34188
Korea

Email: jhpark@nsr.re.kr


Daesung Kwon
National Security Research Institute
P.O. Box 1, Yuseong
Daejeon  34188
Korea

Email: ds_kwon@nsr.re.kr


Dong-Chan Kim
Kookmin University
77 Jeongneung-ro, Seongbuk-gu
Seoul  02707
Korea

Email: dckim@kookmin.ac.kr

that's the whole RFC, bestie πŸŒˆπŸ‘‘πŸ’…

πŸ“¦ where this page comes from