Using GOST Cryptographic Algorithms for JWT security

4.1.1. Content encryption with GM256MGM

This section defines the specifics of performing authenticated encryption with the GOST 34.12-2015 block cipher algorithm with 64-bit block size and 256-bit key length (Magma) as specified in [RFC8891].¶

The algorithms operates in MGM mode as described by [RFC9058].¶

An ICN of size 63 bits MUST be used.¶

The requested size of the Authentication Tag output MUST be equal to 64 bits.¶

4.1.2. Content encryption with GK256MGM

This section defines the specifics of performing authenticated encryption with the GOST 34.12-2015 block cipher algorithm with 128-bit block size and 256-bit key length (Kuznechik) as specified in [RFC7801].¶

The algorithms operates in MGM mode as described by [RFC9058].¶

An ICN of size 127 bits MUST be used.¶

The requested size of the Authentication Tag output MUST be equal to 128 bits.¶

5.1.1. Parameters for Elliptic Curve Public Keys

An Elliptic Curve public key is represented by a pair of coordinates drawn from a finite field, which together define a point on an Elliptic Curve. The following members MUST be present for all Elliptic Curve public keys defined by this specification:¶

• "kty",¶
• "crv"¶
• "x"¶
• "y"¶

  id-tc26-gost-3410-2012-256-paramSetB ::= {iso(1) member-body(2)
        ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1)
        gost-3410-12-256-constants(1) paramSeB(2)}

  id-tc26-gost-3410-2012-256-paramSetC ::= {iso(1) member-body(2)
        ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1)
        gost-3410-12-256-constants(1) paramSeB(3)}

  id-tc26-gost-3410-2012-256-paramSetD ::= {iso(1) member-body(2)
        ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1)
        gost-3410-12-256-constants(1) paramSeB(4)}

5.1.2. Parameters for Elliptic Curve Private Keys

In addition to the members used to represent Elliptic Curve public keys, the following member MUST be present to represent Elliptic Curve private keys.¶

C.1.1. Encoding

The JWS Protected Header used for this example is:¶

  {"alg":"GS256"}

The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:¶

[123, 34, 97, 108, 103, 34, 58, 34, 71, 83, 50, 53, 54, 34, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJHUzI1NiJ9

The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url- encoded JSON object.)¶

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

To remove potential ambiguities in the representation of the JSON object above, the actual octet sequence representing UTF8(JWS Payload) used in this example is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first, second and third lines, the second and third lines have one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing UTF8(JWS Payload) representation for the JSON object above in this example (using JSON array notation) are:¶

[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]¶

Encoding this JWS Payload as BASE64URL(UTF8(JWS Payload)) gives this value (with line breaks for display purposes only):¶

  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):¶

  eyJhbGciOiJHUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence (using JSON array notation):¶

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 72, 85, 122, 73, 49, 78, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]¶

This example uses the Elliptic Curve key represented in JSON Web Key [RFC7515] format below:¶

  {"kty":"EC",
   "crv":"G01-256XA",
   "x":"ut_Qw1MUq9KPqkdHC2xAF3K7TugHfo9n525D2s5mFZc",
   "y":"Q-acH_dP4uLxdJhZq_Z30cDGD-KND4NZjp-UZWlzWK0",
   "d":"JJk5-qg57cPyqv4PZD3kRjySSrvqxqcyMN1cPmIdz78"}

The GOST R 34.10-2012 Signature Algorithm private part d is then passed to a GOST R 34.10-2012 signing function, which also takes the curve type (G01-256XA) and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. In this example, the signature algorithm uses the random k value in the following big-endian octet sequence representation (using JSON array notation):¶

[87, 130, 197, 63, 17, 12, 89, 111, 145, 85, 211, 94, 189, 37, 160, 106, 137, 197, 3, 145, 133, 10, 143, 239, 227, 59, 14, 39, 3, 24, 133, 124]¶

The S value, given as octet sequences representing big-endian integers, is:¶

[45, 185, 213, 66, 201, 34, 203, 38, 204, 35, 107, 25, 88, 110, 89, 177, 208, 113, 62, 133, 236, 170, 57, 59, 39, 13, 27, 155, 171, 222, 166, 161]¶

The R value, given as octet sequences representing big-endian integers, is:¶

[233, 50, 58, 94, 136, 221, 135, 251, 124, 114, 67, 131, 191, 254, 124, 236, 212, 185, 255, 162, 172, 51, 190, 239, 115, 165, 161, 247, 67, 64, 79, 107]¶

The JWS Signature is the value S || R. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):¶

  LbnVQskiyybMI2sZWG5ZsdBxPoXsqjk7Jw0bm6vepqHpMjpeiN2H-3xyQ4O__nzs
  1Ln_oqwzvu9zpaH3Q0BPaw

Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):¶

  eyJhbGciOiJHUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  LbnVQskiyybMI2sZWG5ZsdBxPoXsqjk7Jw0bm6vepqHpMjpeiN2H-3xyQ4O__nzs
  1Ln_oqwzvu9zpaH3Q0BPaw

C.1.2. Validating

Since the "alg" Header Parameter is "GS256", we validate the GOST R 34.10-2012 G01-256XA digital signature contained in the JWS Signature.¶

We need to split the 64 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 32 octet sequences, the first representing S and the second R. We then pass the public key (x, y), the signature (S, R), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to a GOST R 34.10-2012 signature verifier that has been configured to use the G01-256XA curve with the GOST R 34.11-2012 (256) hash function.¶

C.2.1. Encoding

The JWS Protected Header for this example is:¶

  {"alg":"GS512"}

The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:¶

[123, 34, 97, 108, 103, 34, 58, 34, 71, 83, 53, 49, 50, 34, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJHUzUxMiJ9

The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.¶

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):¶

  eyJhbGciOiJHUzUxMiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence:¶

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 72, 85, 122, 85, 120, 77, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]¶

This example uses the Elliptic Curve key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only):¶

  {"kty":"EC",
   "crv":"G12-512B",
   "x":"ExkPVQojORURgkPDBM9hdXQDaoWhLssGvAm8Tp072hiaRUFV0MJMLyxQCo
  e4ZOeNrzhLcaSrUwl3xn_OJ0YTBw",
   "y":"_Q9bZeAc2eO_yhxrsQhTBufa1Fuou2oe_jUOaG6RAtUUvRzhNTppRGGl1-
  EIY2vzzUua9j9Ol_gAoy_LNKQIfg",
   "d":"SwfLa04BTqTmfQxfF_0z_UiMtO7IdrmH5XwHQeYwdXU1JEbuWqArmWee_o
  1SgPO3beZBTHeCtC6XX-zU3BzAPw"}

The GOST R 34.10-2012 Signature Algorithm private part d is then passed to a GOST R 34.10-2012 signing function, which also takes the curve type (G12-512B) and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. In this example, the signature algorithm uses the random k value in the following big-endian octet sequence representation (using JSON array notation):¶

[114, 171, 180, 69, 54, 101, 107, 241, 97, 140, 225, 11, 247, 234, 221, 64, 88, 35, 4, 165, 30, 228, 226, 162, 90, 10, 50, 203, 14, 119, 58, 187, 35, 183, 216, 253, 216, 250, 94, 238, 145, 180, 174, 69, 47, 34, 114, 200, 110, 30, 34, 33, 33, 93, 64, 95, 81, 181, 213, 1, 86, 22, 225, 246]¶

The S value, given as octet sequences representing big-endian integers, is:¶

[4, 77, 220, 231, 27, 212, 139, 107, 136, 53, 250, 89, 79, 252, 60, 30, 241, 66, 223, 9, 153, 223, 231, 102, 67, 84, 187, 225, 132, 246, 126, 103, 73, 214, 205, 47, 188, 3, 211, 249, 211, 235, 40, 182, 149, 197, 66, 14, 254, 184, 90, 167, 31, 247, 72, 208, 16, 193, 88, 248, 42, 97, 121, 124]¶

The R value, given as octet sequences representing big-endian integers, is:¶

[93, 191, 47, 76, 45, 106, 119, 5, 136, 15, 177, 69, 140, 197, 131, 53, 6, 91, 234, 86, 33, 252, 159, 188, 23, 108, 74, 202, 91, 193, 230, 114, 37, 69, 154, 142, 163, 119, 148, 52, 89, 13, 200, 114, 112, 64, 41, 54, 90, 131, 165, 59, 94, 179, 192, 105, 54, 181, 210, 135, 224, 169, 131, 231]¶

The JWS Signature is the value S || R. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):¶

  BE3c5xvUi2uINfpZT_w8HvFC3wmZ3-dmQ1S74YT2fmdJ1s0vvAPT-dPrKLaVxUIO
  _rhapx_3SNAQwVj4KmF5fF2_L0wtancFiA-xRYzFgzUGW-pWIfyfvBdsSspbweZy
  JUWajqN3lDRZDchycEApNlqDpTtes8BpNrXSh-Cpg-c

Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):¶

  eyJhbGciOiJHUzUxMiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  BE3c5xvUi2uINfpZT_w8HvFC3wmZ3-dmQ1S74YT2fmdJ1s0vvAPT-dPrKLaVxUIO
  _rhapx_3SNAQwVj4KmF5fF2_L0wtancFiA-xRYzFgzUGW-pWIfyfvBdsSspbweZy
  JUWajqN3lDRZDchycEApNlqDpTtes8BpNrXSh-Cpg-c

C.2.2. Validating

Since the "alg" Header Parameter is "GS512", we validate the GOST R 34.10-2012 G12-512B digital signature contained in the JWS Signature.¶

We need to split the 128 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 64 octet sequences, the first representing S and the second R. We then pass the public key (x, y), the signature (S, R), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to a GOST R 34.10-2012 signature verifier that has been configured to use the G12-512B curve with the GOST R 34.11-2012 (512) hash function.¶

C.3.1. Encoding

The following example JWS Protected Header declares that the data structure is a JWT [RFC7519] and the JWS Signing Input is secured using the GOST R 34.11-2012 (256) algorithm.¶

  {"alg":"HG256"}

The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 72, 71, 50, 53, 54, 34, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJIRzI1NiJ9

The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.¶

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):¶

  eyJhbGciOiJIRzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence:¶

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 82, 122, 73, 49, 78, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]¶

HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only):¶

  {"kty":"oct",
   "k":"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8"}

Running the HMAC GOST R 34.11-2012 (256) algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence: [104, 41, 229, 119, 16, 188, 143, 143, 240, 156, 82, 164, 141, 142, 126, 104, 25, 153, 122, 60, 251, 186, 33, 112, 19, 137, 54, 106, 255, 194, 126, 40]¶

Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value:¶

  aCnldxC8j4_wnFKkjY5-aBmZejz7uiFwE4k2av_Cfig

Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):¶

  eyJhbGciOiJIRzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  aCnldxC8j4_wnFKkjY5-aBmZejz7uiFwE4k2av_Cfig

C.3.2. Validating

Since the "alg" Header Parameter is "HG256", we validate the HMAC GOST R 34.11-2012 (256) value contained in the JWS Signature.¶

To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC GOST R 34.11-2012 (256) function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated.¶

C.4.1. Encoding

The following example JWS Protected Header declares that the data structure is a JWT [RFC7519] and the JWS Signing Input is secured using the GOST R 34.11-2012 (512) algorithm.¶

  {"alg":"HG512"}

The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:¶

[123, 34, 97, 108, 103, 34, 58, 34, 72, 71, 53, 49, 50, 34, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJIRzUxMiJ9

The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.¶

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):¶

  eyJhbGciOiJIRzUxMiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence:¶

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 82, 122, 85, 120, 77, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]¶

HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only):¶

  {"kty":"oct",
   "k":"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8"}

Running the HMAC GOST R 34.11-2012 (512) algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence: [132, 23, 160, 213, 116, 252, 203, 6, 213, 232, 32, 243, 120, 175, 164, 213, 152, 24, 186, 91, 137, 5, 166, 240, 218, 69, 92, 76, 197, 141, 225, 198, 48, 154, 219, 92, 247, 31, 8, 192, 182, 26, 162, 255, 146, 41, 211, 19, 100, 175, 232, 174, 172, 130, 21, 169, 208, 170, 75, 42, 152, 178, 32, 100]¶

Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value (with line breaks for display purposes only):¶

  hBeg1XT8ywbV6CDzeK-k1ZgYuluJBabw2kVcTMWN4cYwmttc9x8IwLYaov-SKdMT
  ZK_orqyCFanQqksqmLIgZA

Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):¶

  eyJhbGciOiJIRzUxMiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  hBeg1XT8ywbV6CDzeK-k1ZgYuluJBabw2kVcTMWN4cYwmttc9x8IwLYaov-SKdMT
  ZK_orqyCFanQqksqmLIgZA

C.4.2. Validating

Since the "alg" Header Parameter is "HG512", we validate the HMAC GOST R 34.11-2012 (512) value contained in the JWS Signature.¶

To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC GOST R 34.11-2012 (512) function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated.¶

D.1.1. Content Encryption Key (CEK)

Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is: [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252]¶

D.1.2. Key Encryption

Encrypt the CEK with the recipient's public key using the GKEG-KEXP15M algorithm to produce the JWE Encrypted Key. This example uses the GS256 recipient key pair represented in JSON Web Key format below (with line breaks within values for display purposes only):¶

  {"kty":"EC",
   "crv":"G01-256XA",
   "x":"ut_Qw1MUq9KPqkdHC2xAF3K7TugHfo9n525D2s5mFZc",
   "y":"Q-acH_dP4uLxdJhZq_Z30cDGD-KND4NZjp-UZWlzWK0",
   "d":"JJk5-qg57cPyqv4PZD3kRjySSrvqxqcyMN1cPmIdz78"}

Generate a new ephemeral GS256 G01-256XA key pair (see Section 3.2). In this example, the ephemeral public key value (using JSON array notation) is: [192, 221, 37, 46, 21, 175, 110, 173, 22, 19, 159, 227, 245, 81, 245, 36, 48, 166, 108, 194, 243, 246, 218, 128, 97, 88, 193, 129, 252, 229, 79, 195, 104, 98, 81, 72, 189, 124, 9, 238, 151, 43, 110, 87, 158, 251, 247, 194, 53, 43, 142, 244, 171, 84, 4, 49, 109, 89, 166, 28, 155, 2, 9, 177]¶

Generate a 256-bit random UKM. In this example, the value (using JSON array notation) is: [148, 110, 80, 122, 68, 78, 142, 160, 219, 61, 120, 213, 204, 72, 109, 148, 19, 64, 46, 101, 13, 47, 45, 64, 219, 176, 135, 199, 136, 180, 179, 50]¶

Encoding this UKM as BASE64URL(UKM) gives this value:¶

  lG5QekROjqDbPXjVzEhtlBNALmUNLy1A27CHx4i0szI

The resulting JWE Encrypted Key value is: [48, 129, 209, 48, 103, 48, 54, 4, 32, 223, 126, 204, 60, 86, 27, 72, 159, 132, 140, 34, 185, 76, 172, 216, 182, 39, 180, 0, 88, 14, 139, 162, 139, 117, 129, 231, 35, 127, 41, 50, 37, 4, 8, 166, 171, 114, 63, 139, 253, 138, 88, 6, 8, 42, 133, 3, 7, 1, 1, 5, 1, 48, 45, 4, 32, 148, 110, 80, 122, 68, 78, 142, 160, 219, 61, 120, 213, 204, 72, 109, 148, 19, 64, 46, 101, 13, 47, 45, 64, 219, 176, 135, 199, 136, 180, 179, 50, 6, 9, 42, 133, 3, 7, 1, 1, 7, 1, 1, 48, 102, 48, 31, 6, 8, 42, 133, 3, 7, 1, 1, 1, 1, 48, 19, 6, 7, 42, 133, 3, 2, 2, 36, 0, 6, 8, 42, 133, 3, 7, 1, 1, 2, 2, 3, 67, 0, 4, 64, 192, 221, 37, 46, 21, 175, 110, 173, 22, 19, 159, 227, 245, 81, 245, 36, 48, 166, 108, 194, 243, 246, 218, 128, 97, 88, 193, 129, 252, 229, 79, 195, 104, 98, 81, 72, 189, 124, 9, 238, 151, 43, 110, 87, 158, 251, 247, 194, 53, 43, 142, 244, 171, 84, 4, 49, 109, 89, 166, 28, 155, 2, 9, 177]¶

Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):¶

  MIHRMGcwNgQg337MPFYbSJ-EjCK5TKzYtie0AFgOi6KLdYHnI38pMiUECKarcj-L
  _YpYBggqhQMHAQEFATAtBCCUblB6RE6OoNs9eNXMSG2UE0AuZQ0vLUDbsIfHiLSz
  MgYJKoUDBwEBBwEBMGYwHwYIKoUDBwEBAQEwEwYHKoUDAgIkAAYIKoUDBwEBAgID
  QwAEQMDdJS4Vr26tFhOf4_VR9SQwpmzC8_bagGFYwYH85U_DaGJRSL18Ce6XK25X
  nvv3wjUrjvSrVAQxbVmmHJsCCbE

D.1.3. Encoding JWE Protected Header

The following example JWE Protected Header declares that:¶

• The Content Encryption Key is encrypted to the recipient using the GKEG-KEXP15M algorithm to produce the JWE Encrypted Key.¶
• Authenticated encryption is performed on the plaintext using the GM256MGM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.¶
• Key encryption in performed using the specified "ukm" and "epk" values as in Section 3.2.¶

  {"alg":"GKEG-KEXP15M",
   "enc":"GM256MGM",
   "ukm": lG5QekROjqDbPXjVzEhtlBNALmUNLy1A27CHx4i0szI,
   "epk":
    {"kty":"EC",
     "crv":"G01-256XA",
     "x":"wN0lLhWvbq0WE5_j9VH1JDCmbMLz9tqAYVjBgfzlT8M",
     "y":"aGJRSL18Ce6XK25Xnvv3wjUrjvSrVAQxbVmmHJsCCbE"}}

In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between all lines, the second, third and fourth lines have one leading space (32) and no trailing spaces, fifth line have two leading spaces (32, 32), sixth, seventh and eighth lines have three leading spaces (32, 32, 32), the last (eighth) line does not have a terminating line break.) The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 75, 69, 71, 45, 75, 69, 88, 80, 49, 53, 77, 34, 44, 13, 10, 32, 34, 101, 110, 99, 34, 58, 34, 71, 77, 50, 53, 54, 77, 71, 77, 34, 44, 13, 10, 32, 34, 117, 107, 109, 34, 58, 32, 108, 71, 53, 81, 101, 107, 82, 79, 106, 113, 68, 98, 80, 88, 106, 86, 122, 69, 104, 116, 108, 66, 78, 65, 76, 109, 85, 78, 76, 121, 49, 65, 50, 55, 67, 72, 120, 52, 105, 48, 115, 122, 73, 44, 13, 10, 32, 34, 101, 112, 107, 34, 58, 32, 13, 10, 32, 32, 123, 34, 107, 116, 121, 34, 58, 34, 69, 67, 34, 44, 13, 10, 32, 32, 32, 34, 99, 114, 118, 34, 58, 34, 71, 48, 49, 45, 50, 53, 54, 88, 65, 34, 44, 13, 10, 32, 32, 32, 34, 120, 34, 58, 34, 119, 78, 48, 108, 76, 104, 87, 118, 98, 113, 48, 87, 69, 53, 95, 106, 57, 86, 72, 49, 74, 68, 67, 109, 98, 77, 76, 122, 57, 116, 113, 65, 89, 86, 106, 66, 103, 102, 122, 108, 84, 56, 77, 34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34, 97, 71, 74, 82, 83, 76, 49, 56, 67, 101, 54, 88, 75, 50, 53, 88, 110, 118, 118, 51, 119, 106, 85, 114, 106, 118, 83, 114, 86, 65, 81, 120, 98, 86, 109, 109, 72, 74, 115, 67, 67, 98, 69, 34, 125, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJHS0VHLUtFWFAxNU0iLA0KICJlbmMiOiJHTTI1Nk1HTSIsDQogInVr
  bSI6IGxHNVFla1JPanFEYlBYalZ6RWh0bEJOQUxtVU5MeTFBMjdDSHg0aTBzekks
  DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi
  LA0KICAgIngiOiJ3TjBsTGhXdmJxMFdFNV9qOVZIMUpEQ21iTUx6OXRxQVlWakJn
  ZnpsVDhNIiwNCiAgICJ5IjoiYUdKUlNMMThDZTZYSzI1WG52djN3alVyanZTclZB
  UXhiVm1tSEpzQ0NiRSJ9fQ

D.1.4. Initialization Vector

Generate a random 63-bit ICN value. JWE Initialization Vector is formed from the ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0. In this example, the value of JWE Initialization Vector is:¶

[83, 43, 152, 248, 165, 29, 6, 100]¶

Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:¶

  UyuY-KUdBmQ

D.1.5. Additional Authenticated Data

Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]¶

D.1.6. Content Encryption

Perform authenticated encryption on the plaintext with the GM256MGM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 64-bit Authentication Tag output. The resulting ciphertext is: [50, 91, 27, 183, 32, 83, 231, 241, 60, 4, 242, 50, 99, 252, 51, 184, 116, 25, 86, 66, 217, 233, 152, 41, 149, 36, 48, 64, 87, 149, 112, 40, 62, 198, 146, 20, 49, 154, 201, 149, 170, 253, 235, 108, 104, 112, 17, 37, 236, 132, 190, 10, 86, 35, 22, 184, 104, 200, 47, 124, 252, 162, 6]¶

The resulting Authentication Tag value is: [29, 37, 204, 100, 127, 119, 138, 55]¶

Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only):¶

  MlsbtyBT5_E8BPIyY_wzuHQZVkLZ6ZgplSQwQFeVcCg-xpIUMZrJlar962xocBEl
  7IS-ClYjFrhoyC98_KIG

Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:¶

  HSXMZH93ijc

D.1.7. Complete Representation

Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).¶

The final result in this example (with line breaks for display purposes only) is:¶

  eyJhbGciOiJHS0VHLUtFWFAxNU0iLA0KICJlbmMiOiJHTTI1Nk1HTSIsDQogInVr
  bSI6IGxHNVFla1JPanFEYlBYalZ6RWh0bEJOQUxtVU5MeTFBMjdDSHg0aTBzekks
  DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi
  LA0KICAgIngiOiJ3TjBsTGhXdmJxMFdFNV9qOVZIMUpEQ21iTUx6OXRxQVlWakJn
  ZnpsVDhNIiwNCiAgICJ5IjoiYUdKUlNMMThDZTZYSzI1WG52djN3alVyanZTclZB
  UXhiVm1tSEpzQ0NiRSJ9fQ
  .
  MIHRMGcwNgQg337MPFYbSJ-EjCK5TKzYtie0AFgOi6KLdYHnI38pMiUECKarcj-L
  _YpYBggqhQMHAQEFATAtBCCUblB6RE6OoNs9eNXMSG2UE0AuZQ0vLUDbsIfHiLSz
  MgYJKoUDBwEBBwEBMGYwHwYIKoUDBwEBAQEwEwYHKoUDAgIkAAYIKoUDBwEBAgID
  QwAEQMDdJS4Vr26tFhOf4_VR9SQwpmzC8_bagGFYwYH85U_DaGJRSL18Ce6XK25X
  nvv3wjUrjvSrVAQxbVmmHJsCCbE
  .
  UyuY-KUdBmQ
  .
  MlsbtyBT5_E8BPIyY_wzuHQZVkLZ6ZgplSQwQFeVcCg-xpIUMZrJlar962xocBEl
  7IS-ClYjFrhoyC98_KIG
  .
  HSXMZH93ijc

D.1.8. Validation

This example illustrates the process of creating a JWE with GKEG-KEXP15M with GS256 G01-256XA for key encryption and GM256MGM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the GKEG-KEXP15M with GS256 G01-256XA computation includes random values, the encryption results above will not be completely reproducible. However, since the GM256MGM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.¶

D.2.1. Content Encryption Key (CEK)

Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is:¶

[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252]¶

D.2.2. Key Encryption

Encrypt the CEK with the recipient's public key using the GKEG-KEXP15K algorithm to produce the JWE Encrypted Key. This example uses the GS512 recipient key pair represented in JSON Web Key format below (with line breaks within values for display purposes only):¶

  {"kty":"EC",
   "crv":"G12-512B",
   "x":"ExkPVQojORURgkPDBM9hdXQDaoWhLssGvAm8Tp072hiaRUFV0MJMLyxQCo
  e4ZOeNrzhLcaSrUwl3xn_OJ0YTBw",
   "y":"_Q9bZeAc2eO_yhxrsQhTBufa1Fuou2oe_jUOaG6RAtUUvRzhNTppRGGl1-
  EIY2vzzUua9j9Ol_gAoy_LNKQIfg",
   "d":"SwfLa04BTqTmfQxfF_0z_UiMtO7IdrmH5XwHQeYwdXU1JEbuWqArmWee_o
  1SgPO3beZBTHeCtC6XX-zU3BzAPw"}

Generate a new ephemeral GS512 G12-512B key pair (see Section 3.2). In this example, the ephemeral public key value (using JSON array notation) is: [151, 247, 206, 137, 37, 38, 141, 50, 250, 217, 221, 125, 119, 138, 219, 237, 221, 160, 234, 67, 78, 70, 170, 235, 102, 65, 64, 206, 122, 117, 166, 72, 49, 201, 24, 182, 148, 235, 68, 106, 253, 203, 89, 187, 240, 218, 7, 214, 146, 242, 167, 99, 84, 50, 56, 100, 239, 197, 141, 181, 245, 163, 184, 58, 159, 37, 99, 198, 118, 28, 29, 194, 166, 4, 238, 230, 225, 60, 131, 34, 217, 185, 85, 244, 124, 122, 46, 98, 56, 93, 51, 98, 212, 183, 72, 207, 90, 184, 50, 220, 61, 242, 242, 33, 37, 81, 45, 24, 62, 61, 64, 104, 28, 195, 236, 222, 68, 42, 60, 201, 116, 54, 4, 0, 101, 149, 63, 124]¶

Generate a 256-bit random UKM. In this example, the value (using JSON array notation) is: [173, 210, 100, 181, 116, 88, 223, 200, 188, 16, 110, 178, 209, 190, 142, 212, 61, 28, 164, 169, 183, 249, 36, 214, 190, 194, 56, 165, 238, 80, 226, 249]¶

Encoding this UKM as BASE64URL(UKM) gives this value:¶

  rdJktXRY38i8EG6y0b6O1D0cpKm3-STWvsI4pe5Q4vk

The resulting JWE Encrypted Key value is: [48, 130, 1, 30, 48, 111, 48, 62, 4, 32, 132, 139, 65, 112, 240, 108, 131, 132, 143, 123, 234, 212, 93, 160, 181, 113, 175, 165, 108, 146, 142, 198, 86, 107, 112, 33, 182, 158, 235, 206, 60, 242, 4, 16, 123, 152, 177, 84, 181, 139, 166, 84, 63, 203, 78, 201, 99, 11, 208, 243, 6, 8, 42, 133, 3, 7, 1, 1, 5, 2, 48, 45, 4, 32, 173, 210, 100, 181, 116, 88, 223, 200, 188, 16, 110, 178, 209, 190, 142, 212, 61, 28, 164, 169, 183, 249, 36, 214, 190, 194, 56, 165, 238, 80, 226, 249, 6, 9, 42, 133, 3, 7, 1, 1, 7, 2, 1, 48, 129, 170, 48, 33, 6, 8, 42, 133, 3, 7, 1, 1, 1, 2, 48, 21, 6, 9, 42, 133, 3, 7, 1, 2, 1, 2, 2, 6, 8, 42, 133, 3, 7, 1, 1, 2, 3, 3, 129, 132, 0, 4, 129, 128, 151, 247, 206, 137, 37, 38, 141, 50, 250, 217, 221, 125, 119, 138, 219, 237, 221, 160, 234, 67, 78, 70, 170, 235, 102, 65, 64, 206, 122, 117, 166, 72, 49, 201, 24, 182, 148, 235, 68, 106, 253, 203, 89, 187, 240, 218, 7, 214, 146, 242, 167, 99, 84, 50, 56, 100, 239, 197, 141, 181, 245, 163, 184, 58, 159, 37, 99, 198, 118, 28, 29, 194, 166, 4, 238, 230, 225, 60, 131, 34, 217, 185, 85, 244, 124, 122, 46, 98, 56, 93, 51, 98, 212, 183, 72, 207, 90, 184, 50, 220, 61, 242, 242, 33, 37, 81, 45, 24, 62, 61, 64, 104, 28, 195, 236, 222, 68, 42, 60, 201, 116, 54, 4, 0, 101, 149, 63, 124]¶

Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):¶

  MIIBHjBvMD4EIISLQXDwbIOEj3vq1F2gtXGvpWySjsZWa3Ahtp7rzjzyBBB7mLFU
  tYumVD_LTsljC9DzBggqhQMHAQEFAjAtBCCt0mS1dFjfyLwQbrLRvo7UPRykqbf5
  JNa-wjil7lDi-QYJKoUDBwEBBwIBMIGqMCEGCCqFAwcBAQECMBUGCSqFAwcBAgEC
  AgYIKoUDBwEBAgMDgYQABIGAl_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1
  pkgxyRi2lOtEav3LWbvw2gfWkvKnY1QyOGTvxY219aO4Op8lY8Z2HB3CpgTu5uE8
  gyLZuVX0fHouYjhdM2LUt0jPWrgy3D3y8iElUS0YPj1AaBzD7N5EKjzJdDYEAGWV
  P3w

D.2.3. Encoding JWE Protected Header

The following example JWE Protected Header declares that:¶

• The Content Encryption Key is encrypted to the recipient using the GKEG-KEXP15K algorithm to produce the JWE Encrypted Key.¶
• Authenticated encryption is performed on the plaintext using the GK256MGM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.¶
• Key encryption in performed using the specified "ukm" and "epk" values as in Section 3.2.¶

The line breaks in the example below are for display purposes only.¶

  {"alg":"GKEG-KEXP15K",
   "enc":"GK256MGM",
   "ukm": rdJktXRY38i8EG6y0b6O1D0cpKm3-STWvsI4pe5Q4vk,
   "epk":
    {"kty":"EC",
     "crv":"G12-512B",
     "x":"l_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1pkgxyRi2lOtEav3L
  Wbvw2gfWkvKnY1QyOGTvxY219aO4Og",
     "y":"nyVjxnYcHcKmBO7m4TyDItm5VfR8ei5iOF0zYtS3SM9auDLcPfLyISVR
  LRg-PUBoHMPs3kQqPMl0NgQAZZU_fA"}}

The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 75, 69, 71, 45, 75, 69, 88, 80, 49, 53, 75, 34, 44, 13, 10, 32, 34, 101, 110, 99, 34, 58, 34, 71, 75, 50, 53, 54, 77, 71, 77, 34, 44, 13, 10, 32, 34, 117, 107, 109, 34, 58, 32, 114, 100, 74, 107, 116, 88, 82, 89, 51, 56, 105, 56, 69, 71, 54, 121, 48, 98, 54, 79, 49, 68, 48, 99, 112, 75, 109, 51, 45, 83, 84, 87, 118, 115, 73, 52, 112, 101, 53, 81, 52, 118, 107, 44, 13, 10, 32, 34, 101, 112, 107, 34, 58, 32, 13, 10, 32, 32, 123, 34, 107, 116, 121, 34, 58, 34, 69, 67, 34, 44, 13, 10, 32, 32, 32, 34, 99, 114, 118, 34, 58, 34, 71, 49, 50, 45, 53, 49, 50, 66, 34, 44, 13, 10, 32, 32, 32, 34, 120, 34, 58, 34, 108, 95, 102, 79, 105, 83, 85, 109, 106, 84, 76, 54, 50, 100, 49, 57, 100, 52, 114, 98, 55, 100, 50, 103, 54, 107, 78, 79, 82, 113, 114, 114, 90, 107, 70, 65, 122, 110, 112, 49, 112, 107, 103, 120, 121, 82, 105, 50, 108, 79, 116, 69, 97, 118, 51, 76, 87, 98, 118, 119, 50, 103, 102, 87, 107, 118, 75, 110, 89, 49, 81, 121, 79, 71, 84, 118, 120, 89, 50, 49, 57, 97, 79, 52, 79, 103, 34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34, 110, 121, 86, 106, 120, 110, 89, 99, 72, 99, 75, 109, 66, 79, 55, 109, 52, 84, 121, 68, 73, 116, 109, 53, 86, 102, 82, 56, 101, 105, 53, 105, 79, 70, 48, 122, 89, 116, 83, 51, 83, 77, 57, 97, 117, 68, 76, 99, 80, 102, 76, 121, 73, 83, 86, 82, 76, 82, 103, 45, 80, 85, 66, 111, 72, 77, 80, 115, 51, 107, 81, 113, 80, 77, 108, 48, 78, 103, 81, 65, 90, 90, 85, 95, 102, 65, 34, 125, 125]¶

Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:¶

  eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr
  bSI6IHJkSmt0WFJZMzhpOEVHNnkwYjZPMUQwY3BLbTMtU1RXdnNJNHBlNVE0dmss
  DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs
  DQogICAieCI6ImxfZk9pU1VtalRMNjJkMTlkNHJiN2QyZzZrTk9ScXJyWmtGQXpu
  cDFwa2d4eVJpMmxPdEVhdjNMV2J2dzJnZldrdktuWTFReU9HVHZ4WTIxOWFPNE9n
  IiwNCiAgICJ5IjoibnlWanhuWWNIY0ttQk83bTRUeURJdG01VmZSOGVpNWlPRjB6
  WXRTM1NNOWF1RExjUGZMeUlTVlJMUmctUFVCb0hNUHMza1FxUE1sME5nUUFaWlVf
  ZkEifX0

D.2.4. Initialization Vector

Generate a random 127-bit ICN value. JWE Initialization Vector is formed from the ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0. In this example, the value of JWE Initialization Vector is: [211, 184, 87, 139, 135, 193, 115, 153, 171, 62, 127, 65, 58, 208, 233, 14]¶

Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:¶

  07hXi4fBc5mrPn9BOtDpDg

D.2.5. Additional Authenticated Data

Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]¶

D.2.6. Content Encryption

Perform authenticated encryption on the plaintext with the GM256MGM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 128-bit Authentication Tag output. The resulting ciphertext is: [80, 97, 199, 79, 209, 179, 219, 183, 56, 223, 224, 182, 132, 21, 231, 171, 153, 253, 218, 90, 33, 80, 123, 163, 67, 104, 128, 238, 131, 115, 10, 106, 11, 201, 142, 173, 113, 72, 34, 47, 126, 199, 49, 187, 189, 69, 139, 113, 85, 246, 253, 183, 10, 108, 196, 5, 128, 111, 152, 87, 110, 88, 180]¶

The resulting Authentication Tag value is: [189, 77, 119, 49, 71, 200, 0, 125, 197, 72, 201, 108, 80, 52, 231, 54]¶

Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only):¶

  UGHHT9Gz27c43-C2hBXnq5n92lohUHujQ2iA7oNzCmoLyY6tcUgiL37HMbu9RYtx
  Vfb9twpsxAWAb5hXbli0

Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:¶

  vU13MUfIAH3FSMlsUDTnNg

D.2.7. Complete Representation

Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).¶

The final result in this example (with line breaks for display purposes only) is:¶

  eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr
  bSI6IHJkSmt0WFJZMzhpOEVHNnkwYjZPMUQwY3BLbTMtU1RXdnNJNHBlNVE0dmss
  DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs
  DQogICAieCI6ImxfZk9pU1VtalRMNjJkMTlkNHJiN2QyZzZrTk9ScXJyWmtGQXpu
  cDFwa2d4eVJpMmxPdEVhdjNMV2J2dzJnZldrdktuWTFReU9HVHZ4WTIxOWFPNE9n
  IiwNCiAgICJ5IjoibnlWanhuWWNIY0ttQk83bTRUeURJdG01VmZSOGVpNWlPRjB6
  WXRTM1NNOWF1RExjUGZMeUlTVlJMUmctUFVCb0hNUHMza1FxUE1sME5nUUFaWlVf
  ZkEifX0
  .
  MIIBHjBvMD4EIISLQXDwbIOEj3vq1F2gtXGvpWySjsZWa3Ahtp7rzjzyBBB7mLFU
  tYumVD_LTsljC9DzBggqhQMHAQEFAjAtBCCt0mS1dFjfyLwQbrLRvo7UPRykqbf5
  JNa-wjil7lDi-QYJKoUDBwEBBwIBMIGqMCEGCCqFAwcBAQECMBUGCSqFAwcBAgEC
  AgYIKoUDBwEBAgMDgYQABIGAl_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1
  pkgxyRi2lOtEav3LWbvw2gfWkvKnY1QyOGTvxY219aO4Op8lY8Z2HB3CpgTu5uE8
  gyLZuVX0fHouYjhdM2LUt0jPWrgy3D3y8iElUS0YPj1AaBzD7N5EKjzJdDYEAGWV
  P3w
  .
  07hXi4fBc5mrPn9BOtDpDg
  .
  UGHHT9Gz27c43-C2hBXnq5n92lohUHujQ2iA7oNzCmoLyY6tcUgiL37HMbu9RYtx
  Vfb9twpsxAWAb5hXbli0
  .
  vU13MUfIAH3FSMlsUDTnNg

D.2.8. Validation

This example illustrates the process of creating a JWE with GKEG-KEXP15K with GS512 G12-512B for key encryption and GK256MGM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the GKEG-KEXP15K with GS512 G12-512B computation includes random values, the encryption results above will not be completely reproducible. However, since the GK256MGM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.¶