Using GOST Cryptographic Algorithms for JWT security
draft-makarov-gostjwa-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Artyom Makarov , Georgii A. Sadofev | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-makarov-gostjwa-01
Network Working Group A.O. Makarov, Ed.
Internet-Draft G.A. Sadofev
Intended status: Informational CryptoPro
Expires: 24 December 2026 22 June 2026
Using GOST Cryptographic Algorithms for JWT security
draft-makarov-gostjwa-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Makarov & Sadofev Expires 24 December 2026 [Page 1]
Internet-Draft Using GOST Algorithms for JWT June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Algorithms for Digital Signatures and MACs . . 4
2.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 4
2.2. Digital Signature with GOST R 34.10-2012 . . . . . . . . 5
2.3. HMAC with GOST R 34.11-2012 Functions . . . . . . . . . . 6
3. Cryptographic Algorithms for Key Management . . . . . . . . . 7
3.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 7
3.2. Key agreement using KEG algorithm . . . . . . . . . . . . 8
4. Cryptographic Algorithms for Content Encryption . . . . . . . 9
4.1. "enc" (Encryption Algorithm) Header Parameter Values for
JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Content encryption with GM256MGM . . . . . . . . . . 10
4.1.2. Content encryption with GK256MGM . . . . . . . . . . 10
5. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 10
5.1. Parameters for Elliptic Curve Keys . . . . . . . . . . . 10
5.1.1. Parameters for Elliptic Curve Public Keys . . . . . . 11
5.1.2. Parameters for Elliptic Curve Private Keys . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 16
A.1. Digital Signature Algorithm Identifier Cross-Reference . 16
Appendix B. Values of the Parameter Sets . . . . . . . . . . . . 17
Appendix C. JWS Examples . . . . . . . . . . . . . . . . . . . . 20
C.1. Example JWS Using GS256 G01-256XA . . . . . . . . . . . . 20
C.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 20
C.1.2. Validating . . . . . . . . . . . . . . . . . . . . . 23
C.2. Example JWS Using GS512 G12-512B . . . . . . . . . . . . 23
C.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 23
C.2.2. Validating . . . . . . . . . . . . . . . . . . . . . 26
C.3. Example JWS Using HMAC HG256 . . . . . . . . . . . . . . 26
C.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 26
C.3.2. Validating . . . . . . . . . . . . . . . . . . . . . 28
C.4. Example JWS Using HMAC HG512 . . . . . . . . . . . . . . 28
C.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 28
C.4.2. Validating . . . . . . . . . . . . . . . . . . . . . 30
Appendix D. JWE Examples . . . . . . . . . . . . . . . . . . . . 30
D.1. Using GKEG-KEXP15M GS256 G01-256XA with GM256MGM . . . . 30
D.1.1. Content Encryption Key (CEK) . . . . . . . . . . . . 31
D.1.2. Key Encryption . . . . . . . . . . . . . . . . . . . 31
D.1.3. Encoding JWE Protected Header . . . . . . . . . . . . 32
D.1.4. Initialization Vector . . . . . . . . . . . . . . . . 33
D.1.5. Additional Authenticated Data . . . . . . . . . . . . 33
Makarov & Sadofev Expires 24 December 2026 [Page 2]
Internet-Draft Using GOST Algorithms for JWT June 2026
D.1.6. Content Encryption . . . . . . . . . . . . . . . . . 33
D.1.7. Complete Representation . . . . . . . . . . . . . . . 34
D.1.8. Validation . . . . . . . . . . . . . . . . . . . . . 35
D.2. Using GKEG-KEXP15K GS512 G12-512B with GK256MGM . . . . . 35
D.2.1. Content Encryption Key (CEK) . . . . . . . . . . . . 35
D.2.2. Key Encryption . . . . . . . . . . . . . . . . . . . 35
D.2.3. Encoding JWE Protected Header . . . . . . . . . . . . 37
D.2.4. Initialization Vector . . . . . . . . . . . . . . . . 38
D.2.5. Additional Authenticated Data . . . . . . . . . . . . 39
D.2.6. Content Encryption . . . . . . . . . . . . . . . . . 39
D.2.7. Complete Representation . . . . . . . . . . . . . . . 39
D.2.8. Validation . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. 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) [RFC7515], JSON Web Encryption (JWE) [RFC7516] and
JSON Web Keys (JWK) [RFC7517] specifications. This document also
describes the semantics and operations that are specific to these
algorithms and key types.
1.1. 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 [RFC2119],
[RFC8174] 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 [RFC7515].
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 [RFC7516].
Makarov & Sadofev Expires 24 December 2026 [Page 3]
Internet-Draft Using GOST Algorithms for JWT June 2026
The terms "JSON Web Key (JWK)" and "JWK Set" are defined by the JWK
specification [RFC7517]. The terms "Ciphertext", "Digital
Signature", "Initialization Vector", "Message Authentication Code
(MAC)", and "Plaintext" are defined by the "Internet Security
Glossary, Version 2" [RFC4949].
The term "Base64urlUInt" is defined by the JWA specification
[RFC7518].
2. 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.
2.1. "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 | Digital Signature or | Implementation |
| Value | MAC Algorithm | requirements |
+=============+=========================+================+
| GS256 | GOST R 34.10-2012 (256) | Required |
| | Digital Signature using | |
| | GOST R 34.11-2012 (256) | |
+-------------+-------------------------+----------------+
| GS512 | GOST R 34.10-2012 (512) | Recommended+ |
| | Digital Signature using | |
| | GOST R 34.11-2012 (512) | |
+-------------+-------------------------+----------------+
| HG256 | HMAC using GOST R | Recommended+ |
| | 34.11-2012 (256) | |
+-------------+-------------------------+----------------+
| HG512 | HMAC using GOST R | Recommended+ |
| | 34.11-2012 (512) | |
+-------------+-------------------------+----------------+
Table 1
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.
Makarov & Sadofev Expires 24 December 2026 [Page 4]
Internet-Draft Using GOST Algorithms for JWT June 2026
See Appendix A.1 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.
2.2. 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 [RFC7091], using GOST R
34.11-2012 [RFC6986] cryptographic hash function.
GOST R 34.10-2012 SHOULD be instantiated using elliptic curve
parameters from [RFC7836] and Section 5.1.1.2 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) |
+-------------------+-----------------------------------------+
Table 2
Makarov & Sadofev Expires 24 December 2026 [Page 5]
Internet-Draft Using GOST Algorithms for JWT June 2026
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.
2.3. 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 [RFC2104]. HMAC transformations
based on GOST R 34.11-2012 [!RFC6986] cryptographic hash function
defined in [RFC7836].
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 [RFC2104],
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:
Makarov & Sadofev Expires 24 December 2026 [Page 6]
Internet-Draft Using GOST Algorithms for JWT June 2026
+===================+====================================+
| "alg" Param Value | Digital Signature Algorithm |
+===================+====================================+
| HG256 | HMAC using GOST R 34.11-2012 (256) |
+-------------------+------------------------------------+
| HG512 | HMAC using GOST R 34.11-2012 (512) |
+-------------------+------------------------------------+
Table 3
The HMAC GOST R 34.11-2012 (256) for a JWS is validated by computing
an HMAC value per [RFC2104], 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).
3. Cryptographic Algorithms for Key Management
JWE uses cryptographic algorithms to encrypt or determine the Content
Encryption Key (CEK).
3.1. "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.
Makarov & Sadofev Expires 24 December 2026 [Page 7]
Internet-Draft Using GOST Algorithms for JWT June 2026
+==============+==========================+========+================+
| "alg" Param | Key Management | More | Implementation |
| Value | Algorithm | Header | requirements |
| | | Params | |
+==============+==========================+========+================+
| GKEG-KEXP15M | Key agreement using | ukm, | Required |
| | KEG algorithm and | epk | |
| | KExp15 Magma key | | |
| | wrap algorithm | | |
+--------------+--------------------------+--------+----------------+
| GKEG-KEXP15K | Key agreement using | ukm, | Required |
| | KEG algorithm and | epk | |
| | KExp15 Kuznechik | | |
| | key wrap algorithm | | |
+--------------+--------------------------+--------+----------------+
Table 4
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.
3.2. Key agreement using KEG algorithm
The KEG algorithm for a content encryption key CEK is defined in
section 8.3.1 of [RFC9189].
* 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 Section 5.1.1.2): 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 [RFC7517] public
key value (see Section 5.1.1). 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)
Makarov & Sadofev Expires 24 December 2026 [Page 8]
Internet-Draft Using GOST Algorithms for JWT June 2026
* Calculate the export representation of the CEK using KExp15
algorithm defined in section 8.2.1 of [RFC9189]: K_EXP =
KExp15(CEK, K_Exp_MAC, K_Exp_ENC, UKM[25..(24 + n/2)]) where
either Kuznyechik [RFC7801] (for the "GKEG-KEXP15K" key agreement
algorithm) or Magma [RFC8891] (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.
4. 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 [RFC9058].
4.1. "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" | Content Encryption Algorithm | Implementation |
| Param | | Requirements |
| Value | | |
+==========+=================================+================+
| GM256MGM | Authenticated encryption using | Required |
| | MGM mode ([RFC9058]) with GOST | |
| | 34.12-2015 Magma algorithm | |
| | ([RFC8891]) as E_K function | |
+----------+---------------------------------+----------------+
| GK256MGM | Authenticated encryption using | Required |
| | MGM mode ([RFC9058]) with GOST | |
| | 34.12-2015 Kuznechik algorithm | |
| | ([RFC7801]) as the E_K function | |
+----------+---------------------------------+----------------+
Table 5
All encryption algorithms use a JWE Initialization Vector value and
produce JWE Ciphertext and JWE Authentication Tag values.
Makarov & Sadofev Expires 24 December 2026 [Page 9]
Internet-Draft Using GOST Algorithms for JWT June 2026
The (n-1)-bit ICN value used in MGM mode [RFC9058] 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.
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. Cryptographic Algorithms for Keys
This specification defines asymmetric keys to use with the GOST R
34.10-2012 signature algorithm.
5.1. Parameters for Elliptic Curve Keys
JWKs can represent Elliptic Curve [RFC7091] keys.
Makarov & Sadofev Expires 24 December 2026 [Page 10]
Internet-Draft Using GOST Algorithms for JWT June 2026
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"
5.1.1.1. "kty" (Key Type) Parameter
The "kty" (key type) parameter identifies the cryptographic algorithm
family used with the key as defined in [RFC7517]. Key type value
used by this specification is "EC".
5.1.1.2. "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:
Makarov & Sadofev Expires 24 December 2026 [Page 11]
Internet-Draft Using GOST Algorithms for JWT June 2026
+=========+===========================================+============+
|"crv" | Curve Identifier Value | Coordinate |
|value | | 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 |
+---------+-------------------------------------------+------------+
Table 6
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 [RFC4357];
* 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 [RFC7836].
Makarov & Sadofev Expires 24 December 2026 [Page 12]
Internet-Draft Using GOST Algorithms for JWT June 2026
In addition to these parameter sets, this specification defines the
following three parameter sets according to [R-1323565.1.024-2019]:
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)}
The corresponding values of the parameter sets can be found in
Appendix B.
5.1.1.3. "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".
5.1.1.4. "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".
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.
Makarov & Sadofev Expires 24 December 2026 [Page 13]
Internet-Draft Using GOST Algorithms for JWT June 2026
5.1.2.1. "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).
6. Security Considerations
This entire document is about security considerations.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[R-1323565.1.023-2018]
Federal Agency on Technical Regulating and Metrology,
"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",
R 1323565.1.023-2018, 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
Cryptographic Algorithms for Use with GOST 28147-89, GOST
R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006,
<https://www.rfc-editor.org/info/rfc4357>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
2013, <https://www.rfc-editor.org/info/rfc6986>.
Makarov & Sadofev Expires 24 December 2026 [Page 14]
Internet-Draft Using GOST Algorithms for JWT June 2026
[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
Digital Signature Algorithm", RFC 7091,
DOI 10.17487/RFC7091, December 2013,
<https://www.rfc-editor.org/info/rfc7091>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
<https://www.rfc-editor.org/info/rfc7801>.
[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
on the Cryptographic Algorithms to Accompany the Usage of
Standards GOST R 34.10-2012 and GOST R 34.11-2012",
RFC 7836, DOI 10.17487/RFC7836, March 2016,
<https://www.rfc-editor.org/info/rfc7836>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>.
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>.
Makarov & Sadofev Expires 24 December 2026 [Page 15]
Internet-Draft Using GOST Algorithms for JWT June 2026
[RFC9189] Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST
Cipher Suites for Transport Layer Security (TLS) Protocol
Version 1.2", RFC 9189, DOI 10.17487/RFC9189, March 2022,
<https://www.rfc-editor.org/info/rfc9189>.
8.2. Informative References
[GostXmlDsig]
Smirnov, P., Paramonova, M., Khomenko, M., and A. Makarov,
"Using GOST Algorithms for XML Digital Signatures", May
2022, <https://datatracker.ietf.org/doc/html/draft-
smirnov-xmldsig-05>.
[R-1323565.1.024-2019]
Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security.
Elliptic curve parameters for the cryptographic algorithms
and protocols", R 1323565.1.024-2019, 2019.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Appendix A. 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 [GostXmlDsig] for more information about the names defined by
those documents.
A.1. 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 [RFC8792].
[NOTE: '\' line wrapping per RFC 8792]
Makarov & Sadofev Expires 24 December 2026 [Page 16]
Internet-Draft Using GOST Algorithms for JWT June 2026
+=======+============================================+
| JWS | XML |
+=======+============================================+
| GS256 | urn:ietf:params:xml:ns:cpxmlsec:\ |
| | algorithms:gostr34102012-gostr34112012-256 |
+-------+--------------------------------------------+
| GS512 | urn:ietf:params:xml:ns:cpxmlsec:\ |
| | algorithms:gostr34102012-gostr34112012-512 |
+-------+--------------------------------------------+
Table 7
+=======+===================+
| JWS | OID |
+=======+===================+
| GS256 | 1.2.643.7.1.1.3.2 |
+-------+-------------------+
| GS512 | 1.2.643.7.1.1.3.3 |
+-------+-------------------+
Table 8
Appendix B. Values of the Parameter Sets
Parameter set: id-tc26-gost-3410-2012-256-paramSetB
Makarov & Sadofev Expires 24 December 2026 [Page 17]
Internet-Draft Using GOST Algorithms for JWT June 2026
SEQUENCE
{
OBJECT IDENTIFIER
id-tc26-gost-3410-2012-256-paramSetB
SEQUENCE
{
INTEGER
00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
97
INTEGER
00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
94
INTEGER
A6
INTEGER
00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF 6C 61 10 70 99 5A Dl 00 45 84 IB 09 B7 61 B8
93
INTEGER
00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF 6C 61 10 70 99 5A Dl 00 45 84 IB 09 B7 61 B8
93
INTEGER
01
INTEGER
00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B
76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E
14
}
}
Parameter set: id-tc26-gost-3410-2012-256-paramSetC
Makarov & Sadofev Expires 24 December 2026 [Page 18]
Internet-Draft Using GOST Algorithms for JWT June 2026
SEQUENCE
{
OBJECT IDENTIFIER
id-tc26-gost-3410-2012-256-paramSetC
SEQUENCE
{
INTEGER
00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 OC
99
INTEGER
00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 OC
96
INTEGER
3E 1A F4 19 A2 69 A5 F8 66 A7 D3 C2 5C 3D F8 0A
E9 79 25 93 73 FF 2B 18 2F 49 D4 CE 7E 1B BC 8B
INTEGER
00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 5F 70 0C FF F1 A6 24 E5 E4 97 16 1B CC 8A 19
8F
INTEGER
00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 5F 70 0C FF F1 A6 24 E5 E4 97 16 1B CC 8A 19
8F
INTEGER
01
INTEGER
3F A8 12 43 59 F9 66 80 B8 3D 1C 3E B2 C0 70 E5
C5 45 C9 85 8D 03 EC FB 74 4B F8 D7 17 71 7E FC
}
}
Parameter set: id-tc26-gost-3410-2012-256-paramSetD
Makarov & Sadofev Expires 24 December 2026 [Page 19]
Internet-Draft Using GOST Algorithms for JWT June 2026
SEQUENCE
{
OBJECT IDENTIFIER
id-tc26-gost-3410-2012-256-paramSetD
SEQUENCE
{
INTEGER
00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8
AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
9B
INTEGER
00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8
AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
98
INTEGER
80 5A
INTEGER
00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8
AA 58 2C A3 51 IE DD FB 74 F0 2F 3A 65 98 98 OB
B9
INTEGER
00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8
AA 58 2C A3 51 IE DD FB 74 F0 2F 3A 65 98 98 0B
B9
INTEGER
00
INTEGER
41 EC E5 57 43 71 1A 8C 3C BF 37 83 CD 08 CO EE
4D 4D C4 40 D4 64 1A 8F 36 6E 55 0D FD B3 BB 67
}
}
Appendix C. JWS Examples
The following samples was constructed using the X.509 certificates
from Appendix A.1 and A.3 of [R-1323565.1.023-2018].
This section provides several examples of JWSs using GOST algorithms.
C.1. Example JWS Using GS256 G01-256XA
C.1.1. Encoding
The JWS Protected Header used for this example is:
{"alg":"GS256"}
Makarov & Sadofev Expires 24 December 2026 [Page 20]
Internet-Draft Using GOST Algorithms for JWT June 2026
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):
Makarov & Sadofev Expires 24 December 2026 [Page 21]
Internet-Draft Using GOST Algorithms for JWT June 2026
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:
Makarov & Sadofev Expires 24 December 2026 [Page 22]
Internet-Draft Using GOST Algorithms for JWT June 2026
[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. Example JWS Using GS512 G12-512B
C.2.1. Encoding
The JWS Protected Header for this example is:
{"alg":"GS512"}
Makarov & Sadofev Expires 24 December 2026 [Page 23]
Internet-Draft Using GOST Algorithms for JWT June 2026
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):
Makarov & Sadofev Expires 24 December 2026 [Page 24]
Internet-Draft Using GOST Algorithms for JWT June 2026
{"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
Makarov & Sadofev Expires 24 December 2026 [Page 25]
Internet-Draft Using GOST Algorithms for JWT June 2026
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. Example JWS Using HMAC HG256
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
Makarov & Sadofev Expires 24 December 2026 [Page 26]
Internet-Draft Using GOST Algorithms for JWT June 2026
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
Makarov & Sadofev Expires 24 December 2026 [Page 27]
Internet-Draft Using GOST Algorithms for JWT June 2026
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. Example JWS Using HMAC HG512
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
Makarov & Sadofev Expires 24 December 2026 [Page 28]
Internet-Draft Using GOST Algorithms for JWT June 2026
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):
Makarov & Sadofev Expires 24 December 2026 [Page 29]
Internet-Draft Using GOST Algorithms for JWT June 2026
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.
Appendix D. JWE Examples
This section provides examples of JWE computations.
D.1. 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]
Makarov & Sadofev Expires 24 December 2026 [Page 30]
Internet-Draft Using GOST Algorithms for JWT June 2026
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:
[109, 172, 244, 212, 176, 156, 248, 105, 33, 184, 236, 10, 87, 227,
205, 217, 243, 192, 68, 87, 55, 62, 241, 31, 41, 105, 26, 116, 48,
82, 178, 9, 52, 137, 225, 65, 66, 199, 83, 113, 212, 22, 113, 6, 230,
188, 184, 209, 26, 254, 211, 207, 225, 117, 151, 145, 184, 131, 170,
21, 198, 188, 128, 185]
Generate a 256-bit random UKM. In this example, the value (using
JSON array notation) is:
[109, 4, 127, 53, 124, 252, 46, 12, 186, 216, 24, 0, 161, 121, 137,
215, 154, 14, 170, 245, 145, 146, 33, 113, 217, 23, 1, 255, 182, 160,
16, 157]
Encoding this UKM as BASE64URL(UKM) gives this value:
bQR_NXz8Lgy62BgAoXmJ15oOqvWRkiFx2RcB_7agEJ0
The resulting JWE Encrypted Key value is:
[229, 237, 213, 114, 148, 84, 13, 7, 132, 178, 133, 102, 61, 152,
202, 206, 9, 87, 28, 235, 189, 123, 78, 113, 60, 0, 196, 232, 163,
13, 185, 69, 232, 135, 31, 64, 206, 39, 187, 143]
Makarov & Sadofev Expires 24 December 2026 [Page 31]
Internet-Draft Using GOST Algorithms for JWT June 2026
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives
this value (with line breaks for display purposes only):
5e3VcpRUDQeEsoVmPZjKzglXHOu9e05xPADE6KMNuUXohx9Azie7jw
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": bQR_NXz8Lgy62BgAoXmJ15oOqvWRkiFx2RcB_7agEJ0,
"epk":
{"kty":"EC",
"crv":"G01-256XA",
"x":"baz01LCc-GkhuOwKV-PN2fPARFc3PvEfKWkadDBSsgk",
"y":"NInhQULHU3HUFnEG5ry40Rr-08_hdZeRuIOqFca8gLk"}}
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, 98, 81, 82, 95, 78, 88, 122, 56, 76, 103, 121, 54, 50,
66, 103, 65, 111, 88, 109, 74, 49, 53, 111, 79, 113, 118, 87, 82,
107, 105, 70, 120, 50, 82, 99, 66, 95, 55, 97, 103, 69, 74, 48, 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, 98, 97, 122, 48, 49, 76, 67,
99, 45, 71, 107, 104, 117, 79, 119, 75, 86, 45, 80, 78, 50, 102, 80,
65, 82, 70, 99, 51, 80, 118, 69, 102, 75, 87, 107, 97, 100, 68, 66,
83, 115, 103, 107, 34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34,
Makarov & Sadofev Expires 24 December 2026 [Page 32]
Internet-Draft Using GOST Algorithms for JWT June 2026
78, 73, 110, 104, 81, 85, 76, 72, 85, 51, 72, 85, 70, 110, 69, 71,
53, 114, 121, 52, 48, 82, 114, 45, 48, 56, 95, 104, 100, 90, 101, 82,
117, 73, 79, 113, 70, 99, 97, 56, 103, 76, 107, 34, 125, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJHS0VHLUtFWFAxNU0iLA0KICJlbmMiOiJHTTI1Nk1HTSIsDQogInVr
bSI6IGJRUl9OWHo4TGd5NjJCZ0FvWG1KMTVvT3F2V1JraUZ4MlJjQl83YWdFSjAs
DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi
LA0KICAgIngiOiJiYXowMUxDYy1Ha2h1T3dLVi1QTjJmUEFSRmMzUHZFZktXa2Fk
REJTc2drIiwNCiAgICJ5IjoiTkluaFFVTEhVM0hVRm5FRzVyeTQwUnItMDhfaGRa
ZVJ1SU9xRmNhOGdMayJ9fQ
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:
[72, 125, 154, 199, 20, 135, 39, 139]
Encoding this JWE Initialization Vector as BASE64URL(JWE
Initialization Vector) gives this value:
SH2axxSHJ4s
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:
Makarov & Sadofev Expires 24 December 2026 [Page 33]
Internet-Draft Using GOST Algorithms for JWT June 2026
[249, 128, 123, 163, 85, 131, 136, 248, 104, 214, 207, 175, 112, 206,
253, 135, 78, 169, 73, 101, 149, 92, 21, 238, 63, 167, 251, 217, 100,
201, 100, 47, 255, 71, 30, 172, 10, 143, 202, 223, 150, 47, 102, 78,
82, 122, 187, 213, 165, 154, 91, 13, 201, 107, 12, 9, 252, 234, 74,
23, 108, 69, 163]
The resulting Authentication Tag value is:
[116, 197, 177, 168, 189, 63, 187, 89]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value (with line breaks for display purposes only):
-YB7o1WDiPho1s-vcM79h06pSWWVXBXuP6f72WTJZC__Rx6sCo_K35YvZk5ServV
pZpbDclrDAn86koXbEWj
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
dMWxqL0_u1k
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
bSI6IGJRUl9OWHo4TGd5NjJCZ0FvWG1KMTVvT3F2V1JraUZ4MlJjQl83YWdFSjAs
DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi
LA0KICAgIngiOiJiYXowMUxDYy1Ha2h1T3dLVi1QTjJmUEFSRmMzUHZFZktXa2Fk
REJTc2drIiwNCiAgICJ5IjoiTkluaFFVTEhVM0hVRm5FRzVyeTQwUnItMDhfaGRa
ZVJ1SU9xRmNhOGdMayJ9fQ
.
5e3VcpRUDQeEsoVmPZjKzglXHOu9e05xPADE6KMNuUXohx9Azie7jw
.
SH2axxSHJ4s
.
-YB7o1WDiPho1s-vcM79h06pSWWVXBXuP6f72WTJZC__Rx6sCo_K35YvZk5ServV
pZpbDclrDAn86koXbEWj
.
dMWxqL0_u1k
Makarov & Sadofev Expires 24 December 2026 [Page 34]
Internet-Draft Using GOST Algorithms for JWT June 2026
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. 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]
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):
Makarov & Sadofev Expires 24 December 2026 [Page 35]
Internet-Draft Using GOST Algorithms for JWT June 2026
{"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:
[148, 123, 26, 128, 235, 66, 104, 179, 164, 70, 84, 58, 110, 188, 45,
167, 223, 103, 113, 13, 60, 194, 217, 67, 222, 10, 93, 28, 225, 226,
28, 78, 233, 45, 163, 144, 102, 135, 140, 76, 79, 11, 177, 81, 5,
122, 182, 108, 64, 30, 41, 156, 158, 11, 223, 73, 55, 33, 45, 164,
72, 51, 118, 55, 46, 89, 85, 3, 100, 126, 28, 114, 27, 87, 158, 245,
148, 146, 237, 254, 222, 4, 254, 223, 201, 230, 73, 15, 172, 79, 226,
143, 221, 186, 42, 253, 8, 213, 248, 167, 117, 94, 20, 5, 233, 210,
23, 231, 98, 33, 160, 235, 68, 49, 113, 80, 226, 111, 170, 12, 233,
59, 168, 163, 185, 196, 162, 14]
Generate a 256-bit random UKM. In this example, the value (using
JSON array notation) is:
[88, 138, 143, 76, 220, 156, 222, 34, 76, 118, 48, 250, 196, 9, 111,
95, 192, 199, 242, 145, 189, 146, 55, 242, 95, 86, 77, 43, 2, 46,
195, 133]
Encoding this UKM as BASE64URL(UKM) gives this value:
WIqPTNyc3iJMdjD6xAlvX8DH8pG9kjfyX1ZNKwIuw4U
The resulting JWE Encrypted Key value is:
[200, 7, 200, 181, 124, 152, 163, 135, 41, 125, 99, 42, 99, 114, 154,
222, 102, 203, 3, 11, 220, 236, 40, 52, 1, 195, 32, 252, 31, 186,
216, 27, 43, 82, 23, 168, 45, 200, 184, 67, 82, 22, 53, 94, 89, 248,
24, 39]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives
this value (with line breaks for display purposes only):
yAfItXyYo4cpfWMqY3Ka3mbLAwvc7Cg0AcMg_B-62BsrUheoLci4Q1IWNV5Z-Bgn
Makarov & Sadofev Expires 24 December 2026 [Page 36]
Internet-Draft Using GOST Algorithms for JWT June 2026
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": WIqPTNyc3iJMdjD6xAlvX8DH8pG9kjfyX1ZNKwIuw4U,
"epk":
{"kty":"EC",
"crv":"G12-512B",
"x":"lHsagOtCaLOkRlQ6brwtp99ncQ08wtlD3gpdHOHiHE7pLaOQZoeMTE8L
sVEFerZsQB4pnJ4L30k3IS2kSDN2Nw",
"y":"LllVA2R-HHIbV571lJLt_t4E_t_J5kkPrE_ij926Kv0I1findV4UBenS
F-diIaDrRDFxUOJvqgzpO6ijucSiDg"}}
The octets representing UTF8(JWS Protected Header) in this example
(using JSON array notation) are:
Makarov & Sadofev Expires 24 December 2026 [Page 37]
Internet-Draft Using GOST Algorithms for JWT June 2026
[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, 87, 73, 113, 80, 84, 78, 121, 99, 51, 105, 74, 77, 100,
106, 68, 54, 120, 65, 108, 118, 88, 56, 68, 72, 56, 112, 71, 57, 107,
106, 102, 121, 88, 49, 90, 78, 75, 119, 73, 117, 119, 52, 85, 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, 72, 115, 97, 103, 79, 116, 67,
97, 76, 79, 107, 82, 108, 81, 54, 98, 114, 119, 116, 112, 57, 57,
110, 99, 81, 48, 56, 119, 116, 108, 68, 51, 103, 112, 100, 72, 79,
72, 105, 72, 69, 55, 112, 76, 97, 79, 81, 90, 111, 101, 77, 84, 69,
56, 76, 115, 86, 69, 70, 101, 114, 90, 115, 81, 66, 52, 112, 110, 74,
52, 76, 51, 48, 107, 51, 73, 83, 50, 107, 83, 68, 78, 50, 78, 119,
34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34, 76, 108, 108, 86,
65, 50, 82, 45, 72, 72, 73, 98, 86, 53, 55, 49, 108, 74, 76, 116, 95,
116, 52, 69, 95, 116, 95, 74, 53, 107, 107, 80, 114, 69, 95, 105,
106, 57, 50, 54, 75, 118, 48, 73, 49, 102, 105, 110, 100, 86, 52, 85,
66, 101, 110, 83, 70, 45, 100, 105, 73, 97, 68, 114, 82, 68, 70, 120,
85, 79, 74, 118, 113, 103, 122, 112, 79, 54, 105, 106, 117, 99, 83,
105, 68, 103, 34, 125, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr
bSI6IFdJcVBUTnljM2lKTWRqRDZ4QWx2WDhESDhwRzlramZ5WDFaTkt3SXV3NFUs
DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs
DQogICAieCI6ImxIc2FnT3RDYUxPa1JsUTZicnd0cDk5bmNRMDh3dGxEM2dwZEhP
SGlIRTdwTGFPUVpvZU1URThMc1ZFRmVyWnNRQjRwbko0TDMwazNJUzJrU0ROMk53
IiwNCiAgICJ5IjoiTGxsVkEyUi1ISEliVjU3MWxKTHRfdDRFX3RfSjVra1ByRV9p
ajkyNkt2MEkxZmluZFY0VUJlblNGLWRpSWFEclJERnhVT0p2cWd6cE82aWp1Y1Np
RGcifX0
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:
[96, 58, 147, 45, 168, 211, 179, 116, 68, 35, 75, 60, 214, 117, 96,
125]
Encoding this JWE Initialization Vector as BASE64URL(JWE
Initialization Vector) gives this value:
Makarov & Sadofev Expires 24 December 2026 [Page 38]
Internet-Draft Using GOST Algorithms for JWT June 2026
YDqTLajTs3REI0s81nVgfQ
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:
[95, 230, 182, 55, 19, 43, 197, 64, 56, 250, 115, 96, 247, 10, 196,
238, 54, 230, 245, 18, 229, 83, 38, 17, 24, 233, 248, 5, 8, 99, 56,
254, 213, 211, 227, 91, 253, 135, 224, 16, 113, 9, 8, 101, 244, 191,
189, 228, 69, 104, 246, 165, 166, 190, 19, 52, 83, 225, 161, 155, 66,
21, 60]
The resulting Authentication Tag value is:
[205, 230, 54, 9, 203, 225, 113, 91, 249, 37, 186, 236, 53, 217, 77,
214]
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this
value (with line breaks for display purposes only):
X-a2NxMrxUA4-nNg9wrE7jbm9RLlUyYRGOn4BQhjOP7V0-Nb_YfgEHEJCGX0v73k
RWj2paa-EzRT4aGbQhU8
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication
Tag) gives this value:
zeY2CcvhcVv5JbrsNdlN1g
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).
Makarov & Sadofev Expires 24 December 2026 [Page 39]
Internet-Draft Using GOST Algorithms for JWT June 2026
The final result in this example (with line breaks for display
purposes only) is:
eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr
bSI6IFdJcVBUTnljM2lKTWRqRDZ4QWx2WDhESDhwRzlramZ5WDFaTkt3SXV3NFUs
DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs
DQogICAieCI6ImxIc2FnT3RDYUxPa1JsUTZicnd0cDk5bmNRMDh3dGxEM2dwZEhP
SGlIRTdwTGFPUVpvZU1URThMc1ZFRmVyWnNRQjRwbko0TDMwazNJUzJrU0ROMk53
IiwNCiAgICJ5IjoiTGxsVkEyUi1ISEliVjU3MWxKTHRfdDRFX3RfSjVra1ByRV9p
ajkyNkt2MEkxZmluZFY0VUJlblNGLWRpSWFEclJERnhVT0p2cWd6cE82aWp1Y1Np
RGcifX0
.
yAfItXyYo4cpfWMqY3Ka3mbLAwvc7Cg0AcMg_B-62BsrUheoLci4Q1IWNV5Z-Bgn
.
YDqTLajTs3REI0s81nVgfQ
.
X-a2NxMrxUA4-nNg9wrE7jbm9RLlUyYRGOn4BQhjOP7V0-Nb_YfgEHEJCGX0v73k
RWj2paa-EzRT4aGbQhU8
.
zeY2CcvhcVv5JbrsNdlN1g
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.
Authors' Addresses
Artyom O. Makarov (editor)
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
Phone: +7 (495) 995-48-20
Email: makarov@cryptopro.ru
Georgii A. Sadofev
CryptoPro
18, Suschevsky val
Makarov & Sadofev Expires 24 December 2026 [Page 40]
Internet-Draft Using GOST Algorithms for JWT June 2026
Moscow
127018
Russian Federation
Phone: +7 (495) 995-48-20
Email: sadofiev@cryptopro.com
Makarov & Sadofev Expires 24 December 2026 [Page 41]