Using GOST Cryptographic Algorithms for JWT security CryptoPro
18, Suschevsky val Moscow 127018 RU +7 (495) 995-48-20 makarov@cryptopro.ru
CryptoPro
18, Suschevsky val Moscow 127018 RU +7 (495) 995-48-20 sadofiev@cryptopro.com
General Network Working Group gost cryptography JSON JWT JWS JWE JWA This specification registers cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS), JSON Web Encryption (JWE), and JSON Web Keys (JWK) specifications.
Introduction This document specifies cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS) , JSON Web Encryption (JWE) and JSON Web Keys (JWK) specifications. This document also describes the semantics and operations that are specific to these algorithms and key types.
Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14 , when, and only when, they appear in all capitals, as shown here. The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Payload", "JWS Protected Header", "JWS Signature", "JWS Signing Input", and "Unsecured JWS" are defined by the JWS specification . The terms "JSON Web Encryption (JWE)", "Additional Authenticated Data (AAD)", "Authentication Tag", "Content Encryption Key (CEK)", "Direct Encryption", "Direct Key Agreement", "JWE Authentication Tag", "JWE Ciphertext", "JWE Encrypted Key", "JWE Initialization Vector", "JWE Protected Header", "Key Agreement with Key Wrapping", "Key Encryption", "Key Management Mode", and "Key Wrapping" are defined by the JWE specification . The terms "JSON Web Key (JWK)" and "JWK Set" are defined by the JWK specification . The terms "Ciphertext", "Digital Signature", "Initialization Vector", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" . The term "Base64urlUInt" is defined by the JWA specification .
Cryptographic Algorithms for Digital Signatures and MACs JWS uses cryptographic algorithms to digitally sign or create a MAC of the contents of the JWS Protected Header and the JWS Payload.
"alg" (Algorithm) Header Parameter Values for JWS The table below is the set of "alg" (algorithm) Header Parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections:
"alg" Param Value Digital Signature or MAC Algorithm Implementation requirements
GS256 GOST R 34.10-2012 (256) Digital Signature using GOST R 34.11-2012 (256) Required
GS512 GOST R 34.10-2012 (512) Digital Signature using GOST R 34.11-2012 (512) Recommended+
HG256 HMAC using GOST R 34.11-2012 (256) Recommended+
HG512 HMAC using GOST R 34.11-2012 (512) Recommended+
The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification. See for a table cross-referencing the JWS digital signature and MAC "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
Digital Signature with GOST R 34.10-2012 This section defines the use of the GOST R 34.10-2012 signature algorithm as defined in Section 6 of , using GOST R 34.11-2012 cryptographic hash function. GOST R 34.10-2012 SHOULD be instantiated using elliptic curve parameters from and of this document. The GOST R 34.10-2012 (256) signature using GOST R 34.11-2012 (256) is generated as follows:
  1. Generate a digital signature of the JWS Signing Input using GOST R 34.10-2012 (256) with GOST R 34.11-2012 (256) hash with the desired private key. The output will be the pair (R, S), where R and S are 256-bit unsigned integers.
  2. Turn R and S into octet sequences in big-endian order, with each array being 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values.
  3. Concatenate the two octet sequences in the order S and then R. (Note that some GOST R 34.10-2012 implementations will directly produce this concatenation as their output.)
  4. The resulting 64-octet sequence is the JWS Signature value.
The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:
"alg" Param Value Digital Signature Algorithm
GS256 GOST R 34.10-2012 (256) Digital Signature using GOST R 34.11-2012 (256)
GS512 GOST R 34.10-2012 (512) Digital Signature using GOST R 34.11-2012 (512)
The GOST R 34.10-2012 (256) digital signature using GOST R 34.11-2012 for a JWS is validated as follows:
  1. The JWS Signature value MUST be a 64-octet sequence. If it is not a 64-octet sequence, the validation has failed.
  2. Split the 64-octet sequence into two 32-octet sequences. The first octet sequence represents S, and the second R. The values S and R are represented as octet sequences in big-endian octet order. Turn S and R into 256-bit unsigned integers.
  3. Submit the JWS Signing Input, (R, S) and the public key (x, y) to the GOST R 34.10-2012 (256) validator using GOST R 34.11-2012 (256).
Signing and validation with the GOST R 34.10-2012 (512) using GOST R 34.11-2012 (512) algorithm is performed identically to the procedure for GOST R 34.10-2012 (256) using GOST R 34.11-2012 (256), just using the corresponding hash algorithms with correspondingly larger result values. For GOST R 34.10-2012 (512) using GOST R 34.11-2012 (512), S and R will be 512 bits each, resulting in a 128-octet sequence.
HMAC with GOST R 34.11-2012 Functions Hash-based Message Authentication Codes (HMACs) enable one to use a secret plus a cryptographic hash function to generate a MAC. This can be used to demonstrate that whoever generated the MAC was in possession of the MAC key. The algorithm for implementing and validating HMACs is provided in . HMAC transformations based on GOST R 34.11-2012 [!RFC6986] cryptographic hash function defined in . A key of the same size as the hash output (for instance, 256 bits for "HG256") or larger MUST be used with this algorithm. The HMAC GOST R 34.11-2012 (256) MAC is generated per , using GOST R 34.11-2012 (256) as the hash algorithm "H", using the JWS Signing Input as the "text" value, and using the shared key. The HMAC output value is the JWS Signature. The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is an HMAC value computed using the corresponding algorithm:
"alg" Param Value Digital Signature Algorithm
HG256 HMAC using GOST R 34.11-2012 (256)
HG512 HMAC using GOST R 34.11-2012 (512)
The HMAC GOST R 34.11-2012 (256) for a JWS is validated by computing an HMAC value per , using GOST R 34.11-2012 (256) as the hash algorithm "H", using the received JWS Signing Input as the "text" value, and using the shared key. This computed HMAC value is then compared to the result of base64url decoding the received encoded JWS Signature value. The comparison of the computed HMAC value to the JWS Signature value MUST be done in a constant-time manner to thwart timing attacks. Alternatively, the computed HMAC value can be base64url encoded and compared to the received encoded JWS Signature value (also in a constant-time manner), as this comparison produces the same result as comparing the unencoded values. In either case, if the values match, the HMAC has been validated. Securing content and validation with the GOST R 34.11-2012 (512) algorithm is performed identically to the procedure for HMAC GOST R 34.11-2012 (512), just using the corresponding hash algorithms with correspondingly larger minimum key sizes and result values of 512 bits each for GOST R 34.11-2012 (512).
Cryptographic Algorithms for Key Management JWE uses cryptographic algorithms to encrypt or determine the Content Encryption Key (CEK).
"alg" (Algorithm) Header Parameter Values for JWE The table below is the set of "alg" (algorithm) Header Parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CEK, producing the JWE Encrypted Key, or to use key agreement to agree upon the CEK.
"alg" Param Value Key Management Algorithm More Header Params Implementation requirements
GKEG-KEXP15M Key agreement using KEG algorithm and KExp15 Magma key wrap algorithm ukm, epk Required
GKEG-KEXP15K Key agreement using KEG algorithm and KExp15 Kuznechik key wrap algorithm ukm, epk Required
The More Header Params column indicates what additional Header Parameters are used by the algorithm, beyond "alg", which all use. All produce a JWE Encrypted Key value.
Key agreement using KEG algorithm The KEG algorithm for a content encryption key CEK is defined in section 8.3.1 of .
  • Generate a new ephemeral private key d_eph using the algorithm and parameters of the recipient's public key. A new key MUST be generated for each key agreement operation.
  • Compute a point on the elliptic curve E using the fixed point P specified in the curve's parameters (see ): Q_eph = d_eph * P
  • The public key Q_eph is placed in the "epk" header parameter value. This key is represented as a JSON Web Key public key value (see ). The algorithm and parameters of the generated public key MUST match the algorithm and parameters of the recipient's public key.
  • Generate at random a unique 32-octet string UKM. The base64url encoded UKM value is placed in the value of the "ukm" header parameter.
  • Calculate K_Exp_MAC || K_Exp_ENC = KEG(d_eph, Q_r, UKM)
  • Calculate the export representation of the CEK using KExp15 algorithm defined in section 8.2.1 of : K_EXP = KExp15(CEK, K_Exp_MAC, K_Exp_ENC, UKM[25..(24 + n/2)]) where either Kuznyechik (for the "GKEG-KEXP15K" key agreement algorithm) or Magma (for the "GKEG-KEXP15M" key agreement algorithm) is used as a base block cipher for the encryption and MAC algorithm. n denotes the block length in bytes of the corresponding base encryption algorithm.
Cryptographic Algorithms for Content Encryption JWE uses cryptographic algorithms to encrypt and integrity-protect the plaintext and to integrity-protect the Additional Authenticated Data. All algorithms defined by this specification operate in MGM mode described by .
"enc" (Encryption Algorithm) Header Parameter Values for JWE The table below is the set of "enc" (encryption algorithm) Header Parameter values that are defined by this specification for use with JWE.
"enc" Param Value Content Encryption Algorithm Implementation Requirements
GM256MGM Authenticated encryption using MGM mode () with GOST 34.12-2015 Magma algorithm () as E_K function Required
GK256MGM Authenticated encryption using MGM mode () with GOST 34.12-2015 Kuznechik algorithm () as the E_K function Required
All encryption algorithms use a JWE Initialization Vector value and produce JWE Ciphertext and JWE Authentication Tag values. The (n-1)-bit ICN value used in MGM mode MUST be unique for each message that is encrypted under the given key, where n is the block size in bits of the corresponding cipher. The value included in the "iv" parameter is formed from the MGM mode ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0.
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 . The algorithms operates in MGM mode as described by . An ICN of size 63 bits MUST be used. The requested size of the Authentication Tag output MUST be equal to 64 bits.
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 . The algorithms operates in MGM mode as described by . An ICN of size 127 bits MUST be used. The requested size of the Authentication Tag output MUST be equal to 128 bits.
Cryptographic Algorithms for Keys This specification defines asymmetric keys to use with the GOST R 34.10-2012 signature algorithm.
Parameters for Elliptic Curve Keys JWKs can represent Elliptic Curve keys.
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"
"kty" (Key Type) Parameter The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key as defined in . Key type value used by this specification is "EC".
"crv" (Curve) Parameter The "crv" (curve) parameter identifies the cryptographic curve used with the key. Curve values for algorithms used by this specification are:
  • G01-256A
  • G01-256B
  • G01-256C
  • G12-256A
  • G12-256B
  • G12-256C
  • G12-256D
  • G12-512A
  • G12-512B
  • G12-512C
The "crv" parameter values correspond to the following curve identifiers:
"crv" value Curve Identifier Value Coordinate Size
G01-256A id-GostR3410-2001-CryptoPro-A-ParamSet 32 octets
G01-256B id-GostR3410-2001-CryptoPro-B-ParamSet 32 octets
G01-256C id-GostR3410-2001-CryptoPro-C-ParamSet 32 octets
G01-256XA id-GostR3410-2001-CryptoPro-XchA-ParamSet 32 octets
G01-256XB id-GostR3410-2001-CryptoPro-XchB-ParamSet 32 octets
G12-256A id-tc26-gost-3410-2012-256-paramSetA 32 octets
G12-256B id-tc26-gost-3410-2012-256-paramSetB 32 octets
G12-256C id-tc26-gost-3410-2012-256-paramSetC 32 octets
G12-256D id-tc26-gost-3410-2012-256-paramSetD 32 octets
G12-512A id-tc26-gost-3410-12-512-paramSetA 64 octets
G12-512B id-tc26-gost-3410-12-512-paramSetB 64 octets
G12-512C id-tc26-gost-3410-2012-512-paramSetC 64 octets
Curve identifiers
  • id-GostR3410-2001-CryptoPro-A-ParamSet
  • id-GostR3410-2001-CryptoPro-B-ParamSet
  • id-GostR3410-2001-CryptoPro-C-ParamSet
  • id-GostR3410-2001-CryptoPro-XchA-ParamSet
  • id-GostR3410-2001-CryptoPro-XchB-ParamSet
are defined in ;
  • id-tc26-gost-3410-2012-256-paramSetA
  • id-tc26-gost-3410-12-512-paramSetA
  • id-tc26-gost-3410-12-512-paramSetB
  • id-tc26-gost-3410-2012-512-paramSetC
are defined in . In addition to these parameter sets, this specification defines the following three parameter sets according to : The corresponding values of the parameter sets can be found in .
"x" (X Coordinate) Parameter The "x" (x coordinate) parameter contains the x coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string containing the little-endian representation of the coordinate. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "G12-256A", the octet string MUST be 32 octets long, and 64 octets long for "G12-512A".
"y" (Y Coordinate) Parameter The "y" (y coordinate) parameter contains the y coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string containing the little-endian representation of the coordinate. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "G12-256A", the octet string MUST be 32 octets long, and 64 octets long for "G12-512A".
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.
"d" (ECC Private Key) Parameter The "d" (ECC private key) parameter contains the Elliptic Curve private key value. It is represented as the base64url encoding of the octet string containing the little-endian representation. The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve).
Security Considerations This entire document is about security considerations.
IANA Considerations This document has no IANA actions.
References Normative References Information technology. Cryptographic information security. Usage of GOST R 34.10-2012 and GOST R 34.11-2012 algorithms in certificate, CRL and PKCS#10 certificate request in X.509 public key infrastructure Federal Agency on Technical Regulating and Metrology Informative References Using GOST Algorithms for XML Digital Signatures Information technology. Cryptographic data security. Elliptic curve parameters for the cryptographic algorithms and protocols Federal Agency on Technical Regulating and Metrology
Algorithm Identifier Cross-Reference This appendix contains tables cross-referencing the cryptographic algorithm identifier values defined in this specification with the equivalent identifiers used by other standards and software packages. See for more information about the names defined by those documents.
Digital Signature Algorithm Identifier Cross-Reference This section contains a table cross-referencing the JWS digital signature "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages. The table uses the folding defined in . [NOTE: '\' line wrapping per RFC 8792]
JWS XML
GS256 urn:ietf:params:xml:ns:cpxmlsec:\ algorithms:gostr34102012-gostr34112012-256
GS512 urn:ietf:params:xml:ns:cpxmlsec:\ algorithms:gostr34102012-gostr34112012-512
JWS OID
GS256 1.2.643.7.1.1.3.2
GS512 1.2.643.7.1.1.3.3
Values of the Parameter Sets Parameter set: id-tc26-gost-3410-2012-256-paramSetB Parameter set: id-tc26-gost-3410-2012-256-paramSetC Parameter set: id-tc26-gost-3410-2012-256-paramSetD
JWS Examples The following samples was constructed using the X.509 certificates from Appendix A.1 and A.3 of . This section provides several examples of JWSs using GOST algorithms.
Example JWS Using GS256 G01-256XA
Encoding The JWS Protected Header used for this example is: 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: 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.) 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): Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): 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 format below: 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): 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):
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.
Example JWS Using GS512 G12-512B
Encoding The JWS Protected Header for this example is: 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: 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. Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): 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 format below (with line breaks within values for display purposes only): 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): 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):
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.
Example JWS Using HMAC HG256
Encoding The following example JWS Protected Header declares that the data structure is a JWT and the JWS Signing Input is secured using the GOST R 34.11-2012 (256) algorithm. 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: 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. Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): 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 format below (with line breaks within values for display purposes only): 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: 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):
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.
Example JWS Using HMAC HG512
Encoding The following example JWS Protected Header declares that the data structure is a JWT and the JWS Signing Input is secured using the GOST R 34.11-2012 (512) algorithm. 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: 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. Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): 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 format below (with line breaks within values for display purposes only): 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): 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):
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.
JWE Examples This section provides examples of JWE computations.
Using GKEG-KEXP15M GS256 G01-256XA with GM256MGM This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using GS256 with G01-256XA curve for key encryption and GM256MGM for content encryption. The representation of this plaintext (using JSON array notation) is: [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
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]
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): Generate a new ephemeral GS256 G01-256XA key pair (see ). 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: 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):
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 .
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:
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:
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]
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): Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
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:
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.
Using GKEG-KEXP15K GS512 G12-512B with GK256MGM This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using GS512 with G12-512B curve for key encryption and GK256MGM for content encryption. The representation of this plaintext (using JSON array notation) is: [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
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]
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): Generate a new ephemeral GS512 G12-512B key pair (see ). 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: 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):
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 .
The line breaks in the example below are for display purposes only. 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:
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:
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]
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): Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
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:
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.