]> APMI, Belarusian State University

agievichi@bsu.by

IM, Academy of Sciences of Belarus

kalosha@im.bas-net.by

This specification introduces a subset of STB (STandards of Belarus) cryptographic algorithms and defines their use in TLS 1.3. The document is self-contained, i.e., it fully describes the required STB algorithms. It can be used to develop STB-compliant TLS 1.3 implementations without referring to the original STB standards.

Introduction In the TLS 1.3 protocol , the client and server negotiate the following cryptographic parameters:

1. Hashing and AEAD (Authenticated Encryption with Associated Data) algorithms, which together define a cipher suite. TLS parties specify their preferred cipher suites in the handshake hello messages.
2. KEM (Key Encapsulation Mechanism) algorithms, which are defined implicitly through algebraic group identifiers in the "supported_groups" and "key_share" extensions of hello messages. By default, KEM is implemented through the Diffie-Hellman protocol and cyclic groups for this protocol are assumed.
3. Digital signature algorithms, which are negotiated through the "signature_algorithms" and "signature_algorithms_cert" extensions.

Based on these parameters, the TLS algorithmic stack is constructed, covering key exchange, bulk encryption, message authentication and authentication of parties. Changing the parameters modifies the stack without redesigning its structure. This specification introduces a subset of cryptographic algorithms standardized in Belarus and defines their use as TLS 1.3 cryptographic parameters. These algorithms are deployed across Belarusian IT systems, powering public key infrastructures, legally recognized digital signatures, identity cards, VPN services, etc. The specification aims to improve the recognition of the algorithms, in particular, to obtain assigned code points for the respective TLS parameters. This would ensure interoperability and facilitate interactions with external systems. National standards of Belarus are designated by the abbreviation STB. The relevant standards have additionally been assigned short names:

• Belt (, introduced in 2007): block cipher-based symmetric encryption, data authentication, hashing;
• Bash (, introduced in 2016): sponge function-based symmetric encryption, data authentication, hashing;
• Bign (, introduced in 2011): elliptic curve-based digital signatures and key transport.

These short names are also used to refer to the elements of the standards. This document presents a restricted profile of the STB suite, defining only a subset of the available algorithms and narrowing their operational parameters. The sole exception to this restriction is , where the complete functionality of the auxiliary sponge automaton is specified.

Notation

General

NIL :

empty input, error;

!= :

not equal;

a^b, a^{b} :

b is the upper index of a;

a_b, a_{b} :

b is the lower index of a;

a b, a * b :

multiplication;

{a, b, c, ...} :

the set of elements a, b, c, ...;

a in S :

a belongs to S;

alg(u_1, u_2, ...) :

call an algorithm alg with inputs u_1, u_2, ...;

a <- u :

assign u to a;

a <- S :

for a set S, the same as a <- u, where u is chosen uniformly at random from S;

(a_1, a_2, ...) <- (u_1, u_2, ...) :

the same as a_1 <- u_1, a_2 <- u_2, ...;

(NIL, a_2) <- (u_1, u_2) :

the same as a_2 <- u_2 (u_1 is ignored);

a <-> b :

swap the values of a and b.

Binary Strings and Integers

{0, 1}^* :

the set of all binary strings of finite length (including the empty string of length 0);

|u| :

the bit length of u in {0, 1}^*;

{0, 1}^n :

the set of u in {0, 1}^* such that |u| = n;

{0, 1}^{n*} :

the set of u in {0, 1}^* such that |u| is a multiple of n;

u[i] :

for u in {0, 1}^* and 0 <= i < |u|, the ith bit of u (bits are numbered from zero);

u[:m) :

for u in {0, 1}^n and 0 <= m <= n, the string u[0]u[1]...u[m-1];

u[m:) :

for u in {0, 1}^n and 0 <= m <= n, the string u[m]u[m+1]...u[n-1];

u[-m:) :

for u in {0, 1}^n and 0 <= m <= n, the string u[n-m]...u[n-1];

u[m_1:m_2) :

for u in {0, 1}^n and 0 <= m_1 <= m_2 <= n, the string u[m_1]u[m_1+1]...u[m_2-1];

u || v :

for u, v in {0, 1}^*, their concatenation, that is, the string w of length |u| + |v| such that w[:|u|) = u and w[-|v|:) = v;

Rep(u, m) :

for u in {0, 1}^* and a positive integer m, the concatenation of m copies of u;

Split(u, m) :

for u in {0, 1}^* and a positive integer m, the tuple:

• () if |u| = 0;
• (u) if 0 < |u| <= m;
• (u[:m), Split(u[m:), m)) if |u| > m;

U mod m :

for an integer U and a positive integer m, the integer r in {0, 1, ..., m-1} such that U - r is a multiple of m;

u & v :

for u, v in {0, 1}^n, the string w in {0, 1}^n such that w[i] = u[i] * v[i] (bitwise AND);

u | v :

for u, v in {0, 1}^n, the string w in {0, 1}^n such that w[i] = (u[i] * v[i] + u[i] + v[i]) mod 2 (bitwise OR);

u ^ v :

for u, v in {0, 1}^n, the string w in {0, 1}^n such that w[i] = (u[i] + v[i]) mod 2 (bitwise exclusive OR);

~u :

for u in {0, 1}^n, the string u ^ Rep(1, n) (bitwise NOT);

Bin2Int(u) :

for u in {0, 1}^{8*}, the number:

• 0, if |u| = 0;
• 128 u[0] + 64 u[1] + ... + u[7], if |u| = 8;
• Bin2Int(u[:8)) + 256 * Bin2Int(u[8:)), if |u| > 8 (binary-to-integer conversion);

Int2Bin(U, 8n) :

for a non-negative integer U and a positive integer n, the string u in {0, 1}^{8n} such that Bin2Int(u) = U mod 2^{8n} (integer-to-binary conversion);

u + v :

for u, v in {0, 1}^{8n}, the string Int2Bin(Bin2Int(u) + Bin2Int(v), 8n);

u - v :

for u, v in {0, 1}^{8n}, the string w in {0, 1}^{8n} such that u = w + v;

Floor(z) :

for a real number z, the greatest integer less than or equal to z;

ShLo(u, r) :

for u in {0, 1}^{8n} and a positive integer r < 8n, the string Int2Bin(Floor(Bin2Int(u) / 2^r), 8n);

ShHi(u, r) :

for u in {0, 1}^{8n} and a positive integer r < 8n, the string Int2Bin(2^r * Bin2Int(u), 8n);

RotHi(u, r) :

for u in {0, 1}^{8n} and a positive integer r < 8n, the string ShHi(u, r) ^ ShLo(u, 8n - r).

Miscellaneous

-- :

dash;

\ :

no line break; used to split large sequences of digits into lines for convenience;

0x :

prefix followed by a hexadecimal representation of u in {0, 1}^{4*}:

• every four consecutive bits of u are represented by a hexadecimal digit in {0, 1, ..., 9, A, B, C, D, E, F} (e.g., 10110001 = 0xB1);

OID(obj) :

an identifier of an object obj, a string in {0, 1}^{8*}.

Conventions for i = 1, 2, ..., m :

• the body of the loop is executed m times if m > 1;
• the body of the loop is executed once if m = 1;
• the body of the loop is never executed if m < 1;

(a_1, a_2, ..., a_m):

• a tuple of m elements if m > 1;
• a tuple of one element a_1 if m = 1;
• an empty tuple if m < 1.

u[m_1]u[m_1+1]...u[m_2-1]:

• a string of m_2 - m_1 elements if m_2 > m_1;
• an empty tuple if m_2 <= m_1.

Belt Algorithms

Preliminaries This specification defines the following algorithms of the Belt family:

• belt-block -- block encryption;
• belt-hash -- hashing;
• belt-che256 -- authenticated encryption.

The belt-block algorithms (encryption and decryption) define a block cipher that processes 128-bit blocks using 256-bit keys. This cipher is the basic primitive, all other Belt algorithms are built on top of it. The belt-hash algorithm implements 256-bit hashing. When processing two 128-bit blocks of data, belt-block is invoked 3 times, i.e., the hash rate is approximately 2/3 of the encryption rate. The belt-che256 algorithms (encryption and decryption) implement AEAD in the CHE (Counter-Hash-Encrypt) mode . This mode is similar to the well-known GCM mode , but it is more robust with respect to nonce misuse. The nonce length is 128 bits, and the authentication tag length is 64 bits.

Block Encryption Block encryption is defined by the encryption algorithm belt-block and the corresponding decryption algorithm. This specification describes only encryption. The belt-block algorithm uses auxiliary transformations G_5, G_13, G_21 which, in turn, use an S-box H.

S-box H The S-box H transforms x in {0, 1}^8 as follows.

1. Parse (x_1, x_2) = Split(x, 4).
2. Find the octet y in row x_1 and column x_2 of (all data in the table are in the hexadecimal notation).
3. Return y.

The S-box `H`

	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
0	B1	94	BA	C8	0A	08	F5	3B	36	6D	00	8E	58	4A	5D	E4
1	85	04	FA	9D	1B	B6	C7	AC	25	2E	72	C2	02	FD	CE	0D
2	5B	E3	D6	12	17	B9	61	81	FE	67	86	AD	71	6B	89	0B
3	5C	B0	C0	FF	33	C3	56	B8	35	C4	05	AE	D8	E0	7F	99
4	E1	2B	DC	1A	E2	82	57	EC	70	3F	CC	F0	95	EE	8D	F1
5	C1	AB	76	38	9F	E6	78	CA	F7	C6	F8	60	D5	BB	9C	4F
6	F3	3C	65	7B	63	7C	30	6A	DD	4E	A7	79	9E	B2	3D	31
7	3E	98	B5	6E	27	D3	BC	CF	59	1E	18	1F	4C	5A	B7	93
8	E9	DE	E7	2C	8F	0C	0F	A6	2D	DB	49	F4	6F	73	96	47
9	06	07	53	16	ED	24	7A	37	39	CB	A3	83	03	A9	8B	F6
A	92	BD	9B	1C	E5	D1	41	01	54	45	FB	C9	5E	4D	0E	F2
B	68	20	80	AA	22	7D	64	2F	26	87	F9	34	90	40	55	11
C	BE	32	97	13	43	FC	9A	48	A0	2A	88	5F	19	4B	09	A1
D	7E	CD	A4	D0	15	44	AF	8C	A5	84	50	BF	66	D2	E8	8A
E	A2	D7	46	52	42	A8	DF	B3	69	74	C5	51	EB	23	29	21
F	D4	EF	D9	B4	3A	62	28	75	91	14	10	EA	77	6C	DA	1D

The S-box defines a family of constants BeltH. The family is parameterized by integers u >= 0 and n > 0 such that u + n <= 256. A particular constant BeltH(u, n) is defined as H(Int2Bin(u, 8)) || H(Int2Bin(u + 1, 8)) || ... || H(Int2Bin(u + n - 1, 8)). For example, BeltH(79, 3) = 0xF1C1AB (Int2Bin(79, 8) = 0x4F).

The Transformations G_r The transformations G_5, G_13, G_21 map the set {0, 1}^32 to itself. They are derived from an algorithm G by taking G_r(x) = G(x, r). The algorithm G is defined as follows. Input:

• x in {0, 1}^32;
• r in {5, 13, 21}.

Output:

• y in {0, 1}^32.

Steps:

1. Parse (x_1, x_2, x_3, x_4) = Split(x, 8).
2. y <- RotHi(H(x_1) || H(x_2) || H(x_3) || H(x_4), r).
3. Return y.

The belt-block Algorithm Input:

• X in {0, 1}^128 -- a plaintext block;
• K in {0, 1}^256 -- a key.

Output:

• Y in {0, 1}^128 -- the encrypted block.

Steps:

1. (a, b, c, d) <- Split(X, 32).
2. (k[1], k[2], ..., k[56]) <- Split(Rep(K, 7), 32).
3. For i = 1, 2, ..., 8:
   1. b <- b ^ G_5(a + k[7i-6]);
   2. c <- c ^ G_21(d + k[7i-5]);
   3. a <- a - G_13(b + k[7i-4]);
   4. e <- G_21(b + c + k[7i-3]) ^ Int2Bin(i, 32);
   5. b <- b + e;
   6. c <- c - e;
   7. d <- d + G_13(c + k[7i-2]);
   8. b <- b ^ G_21(a + k[7i-1]);
   9. c <- c ^ G_5(d + k[7i]);
   10. a <-> b;
   11. c <-> d;
   12. b <-> c.
4. Y <- b || d || a || c.
5. Return Y.

Hashing Hashing is defined by the belt-hash algorithm which uses the auxiliary algorithm belt-compress.

The belt-compress Algorithm Input:

• X in {0, 1}^512.

Output:

• S in {0, 1}^128;
• Y in {0, 1}^256.

Steps:

1. Parse (X_1, X_2, X_3, X_4) = Split(X, 128).
2. S <- belt-block(X_3 ^ X_4, X_1 || X_2) ^ X_3 ^ X_4.
3. Y_1 <- belt-block(X_1, S || X_4) ^ X_1.
4. Y_2 <- belt-block(X_2, (S ^ Rep(1, 128)) || X_3) ^ X_2.
5. Return (S, Y), where Y = Y_1 || Y_2.

The belt-hash Algorithm Input:

• X in {0, 1}^* -- data to be hashed.

Output:

• H in {0, 1}^256 -- the hash value.

Steps:

1. Parse (X_1, X_2, ..., X_n) = Split(X, 256).
2. r <- Int2Bin(|X|, 128).
3. s <- Rep(0, 128).
4. h <- BeltH(0, 32).
5. X_n <- X_n || Rep(0, 256 - |X_n|).
6. For i = 1, 2, ..., n:
   1. (t, h) <- belt-compress(X_i || h);
   2. s <- s ^ t.
7. (NIL, H) <- belt-compress(r || s || h).
8. Return H.

Authenticated Encryption Authenticated encryption is defined by the encryption algorithm belt-che256 and the decryption algorithm belt-che256-inv. 128-bit blocks are interpreted as polynomials of degree less than 128 over the binary field {0, 1}. The polynomials are added and multiplied modulo a fixed irreducible polynomial of degree 128. Thus, operations on polynomials are performed in a finite field (Galois field, see ) of size 2^128. The transition from blocks to polynomials and the field multiplication are defined as follows.

u(x):

for u in {0, 1}^{8*}, the polynomial:

• 0, if |u| = 0;
• u[0] x^7 + u[1] x^6 + ... + u[7], if |u| = 8;
• u[:8)(x) + x^8 u[8:)(x), if |u| > 8;

u(x) mod f(x):

for a polynomial u(x) and a nonzero polynomial f(x), the remainder of the division of u(x) by f(x);

u * v:

for u, v in {0, 1}^128, the string w in {0, 1}^128 such that w(x) = u(x) v(x) mod f(x), where f(x) = x^128 + x^7 + x^2 + x + 1.

The algorithms use a constant C in {0, 1}^128 defined as C = 0x02 || Rep(0, 120). Its polynomial representation is C(x) = x.

The belt-che256 Algorithm Input:

• X in {0, 1}^* -- plaintext, |X| < 2^64;
• I in {0, 1}^* -- associated data, |I| < 2^64;
• K in {0, 1}^256 -- a key;
• S in {0, 1}^128 -- a nonce.

Output:

• Y in {0, 1}^{|X|} -- ciphertext;
• T in {0, 1}^64 -- the authentication tag.

Steps:

1. (X_1, X_2, ..., X_n) <- Split(X, 128).
2. (I_1, I_2, ..., I_m) <- Split(I, 128).
3. Set:
   1. s <- belt-block(S, K);
   2. r <- s;
   3. t <- BeltH(0, 16).
4. For i = 1, 2, ..., m:
   1. t <- t ^ (I_i || Rep(0, 128 - |I_i|));
   2. t <- t * r.
5. For i = 1, 2, ..., n:
   1. s <- (s * C) ^ Int2Bin(1, 128);
   2. Y_i <- X_i ^ belt-block(s, K)[:|X_i|);
   3. t <- t ^ (Y_i || Rep(0, 128 - |Y_i|));
   4. t <- t * r.
6. t <- t ^ (Int2Bin(|I|, 64) || Int2Bin(|X|, 64)).
7. t <- belt-block(t * r, K).
8. T <- t[:64).
9. Return (Y, T), where Y = Y_1 || Y_2 || ... || Y_n.

The belt-che256-inv Algorithm Input:

• Y in {0, 1}^* -- ciphertext, |Y| < 2^64;
• I in {0, 1}^* -- associated data, |I| < 2^64;
• T in {0, 1}^64 -- an authentication tag;
• K in {0, 1}^256 -- a key;
• S in {0, 1}^128 -- a nonce.

Output:

• NIL -- an authentication error, or X in {0, 1}^|Y| -- plaintext.

Steps:

1. Parse (Y_1, Y_2, ..., Y_n) = Split(Y, 128).
2. Parse (I_1, I_2, ..., I_m) = Split(I, 128).
3. Set:
   1. s <- belt-block(S, K);
   2. r <- s;
   3. t <- BeltH(0, 16).
4. For i = 1, 2, ..., m:
   1. t <- t ^ (I_i || Rep(0, 128 - |I_i|));
   2. t <- t * r.
5. For i = 1, 2, ..., n:
   1. t <- t ^ (Y_i || Rep(0, 128 - |Y_i|));
   2. t <- t * r.
6. t <- t ^ (Int2Bin(|I|, 64) || Int2Bin(|Y|, 64)).
7. t <- belt-block(t * r, K).
8. If T != t[:64), then return NIL.
9. For i = 1, 2, ..., n:
   1. s <- (s * C) ^ Int2Bin(1, 128);
   2. X_i <- Y_i ^ belt-block(s, K)[:|Y_i|).
10. Return X = X_1 || X_2 || ... || X_n.

Bash Algorithms

Preliminaries This specification defines the following algorithms of the Bash family:

• bash-f -- the base sponge function;
• bash256, bash384, bash512 -- hashing;
• bash-prg-ae2561 -- authenticated encryption.

The bash-f algorithm implements a 1536-bit sponge function, that is, a permutation on the set {0, 1}^1536. The sponge function is the basic primitive for all other Bash algorithms. These algorithms use bash-f either directly or through an abstraction layer called a sponge automaton. The automaton processes a 1536-bit sponge state using a prescribed set of commands on top of bash-f. The design of bash-f is explained in . The bashLLL algorithm, LLL in {256, 384, 512}, implements LLL-bit hashing. The bash-prg-ae2561 algorithms (encryption and decryption) implement AEAD with 256-bit authentication tags and up to 480-bit preambles. Preambles may contain customization strings, public data to be authenticated, nonces and other non-secret objects.

The Sponge Function The sponge function bash-f is defined through an auxiliary algorithm bash-s.

The bash-s Algorithm Input:

• W_0, W_1, W_2 in {0, 1}^64;
• m_1, n_1, m_2, n_2 in {1, 2, ..., 63}.

Output:

• (W_0, W_1, W_2) -- the transformed input strings.

Steps:

1. T_0 <- RotHi(W_0, m_1).
2. W_0 <- W_0 ^ W_1 ^ W_2.
3. T_1 <- W_1 ^ RotHi(W_0, n_1).
4. W_1 <- T_0 ^ T_1.
5. W_2 <- W_2 ^ RotHi(W_2, m_2) ^ RotHi(T_1, n_2).
6. T_0 <- ~W_2.
7. T_1 <- W_0 | W_2.
8. T_2 <- W_0 & W_1.
9. T_0 <- T_0 | W_1.
10. W_1 <- W_1 ^ T_1.
11. W_2 <- W_2 ^ T_2.
12. W_0 <- W_0 ^ T_0.
13. Return (W_0, W_1, W_2).

The bash-f Algorithm Input:

• S in {0, 1}^1536 -- a state.

Output:

• S in {0, 1}^1536 -- the transformed state.

Steps:

1. Parse (S_0, S_1, ..., S_23) = Split(S, 64).
2. C <- Bin2Int(BeltH(0, 8)).
3. For i = 1, 2, ..., 24:
   1. (m_1, n_1, m_2, n_2) <- (8, 53, 14, 1).
   2. for j = 0, 1, ..., 7:
      1. (S_j, S_{8+j}, S_{16+j}) <- bash-s(S_j, S_{8+j}, S_{16+j}, m_1, n_1, m_2, n_2).
      2. m_1 <- (7 * m_1) mod 64, n_1 <- (7 * n_1) mod 64. m_2 <- (7 * m_2) mod 64, n_2 <- (7 * n_2) mod 64.
   3. (S_0, S_1, S_2, S_3, S_4, S_5, S_6, S_7, S_8, S_9, S_10, S_11, S_12, S_13, S_14, S_15, S_16, S_17, S_18, S_19, S_20, S_21, S_22, S_23) <- (S_15, S_10, S_9, S_12, S_11, S_14, S_13, S_8, S_17, S_16, S_19, S_18, S_21, S_20, S_23, S_22, S_6, S_3, S_0, S_5, S_2, S_7, S_4, S_1).
   4. S_23 <- S_23 ^ C.
   5. if C mod 2 = 0, then C <- ShLo(C, 1) else C <- ShLo(C, 1) ^ 0xAED8E07F99E12BDC.
4. Return S_0 || S_1 || ... || S_23.

The Sponge Automaton For reasons of completeness, we describe the full functionality of the Bash automaton. Note that bash-prg-ae2561 uses only a part of this functionality.

States and Parameters An automaton processes a state S in {0, 1}^1536 using the following parameters:

• l in {128, 192, 256} -- security level;
• d in {1, 2} -- capacity level;
• r in {1536 - 2dl, 1536 - l - dl/2} -- buffer length;
• pos in {0, 1, ..., r - 1} -- current buffer offset.

Parameters l and d are set when the automaton is initialized and do not change thereafter. The state S is split into two parts:

1. The buffer S[:r) used for input and output.
2. The internal memory S[r:). The bit S[r] of the memory has a special purpose: the internal command commit inverts it to signal the completion of the previous command.

Commands The state is processed using the following commands:

• start: initialize;
• commit: complete execution of the previous command (internal command, can only be called from other commands);
• restart: re-initialize;
• absorb: process input data;
• squeeze: extract output data;
• encrypt / decrypt: process plaintext / ciphertext;
• ratchet: update the state irreversibly.

The processed data are encoded as follows: Data Types in the Bash Automaton

Type	Description	Code (6 bits)
NULL	Service data	000000
KEY	Key	000001
DATA	Public input data	000010
TEXT	Plaintext or ciphertext	000011
OUT	Output data	000100

The start Command Input:

• A in {0, 1}^{32*} -- a preamble (|A| <= 480);
• K in {0, 1}^{32*} -- a key (|K| <= 480; if K != NIL, then |K| >= l).

Output:

• None.

Steps:

1. If K != NIL, then r <- 1536 - l - dl/2 else r <- 1536 - 2dl.
2. pos <- 8 + |A| + |K|.
3. S[:pos) <- Int2Bin(|A|/2 + |K|/32, 8) || A || K.
4. S[pos:1472) <- Rep(0, 256 - |X_n|).
5. S[1472:) <- Int2Bin(l/4 + d, 64).
6. Store parameters (l, d, r, pos) with state S.

The commit Command Input:

• t in {0, 1}^6 -- data type (see the table above).

Output:

• None.

Steps:

1. S[pos:pos+8) <- S[pos:pos+8) ^ (t || 01).
2. S[r] <- S[r] ^ 1.
3. S <- bash-f(S).
4. pos <- 0.

The restart Command Input:

• A in {0, 1}^{32*} -- a preamble (|A| <= 480);
• K in {0, 1}^{32*} -- a key (|K| <= 480; if K != NIL, then |K| >= l).

Output:

• None.

Steps:

1. If K != NIL, then:
   1. commit(KEY);
   2. r <- 1536 - l - dl/2.
2. Else commit(NULL).
3. pos <- 8 + |A| + |K|.
4. S[:pos) <- S[:pos) ^ (Int2Bin(|A|/2 + |K|/32, 8) || A || K).

The absorb Command Input:

• X in {0, 1}^{8*} -- input data.

Output:

• None.

Steps:

1. commit(DATA).
2. Parse (X_1, ..., X_n) = Split(X, r).
3. For i = 1, 2, ..., n:
   1. pos <- |X_i|;
   2. S[:pos) <- S[:pos) ^ X_i.
   3. if pos = r, then:
      1. S <- bash-f(S);
      2. pos <- 0.

The squeeze Command Input:

• n >= 0 -- output length (multiple of 8).

Output:

• Y in {0, 1}^n.

Steps:

1. commit(OUT).
2. Y <- NIL.
3. While |Y| + r <= n:
   1. Y <- Y || S[:r);
   2. S <- bash-f(S).
4. pos <- n - |Y|.
5. Y <- Y || S[:pos).
6. Return Y.

The encrypt Command Input:

• X in {0, 1}^{8*} -- plaintext.

Output:

• Y in {0, 1}^|X| -- ciphertext.

Steps:

1. commit(TEXT).
2. Parse (X_1, ..., X_n) = Split(X, r).
3. Y <- NIL.
4. For i = 1, 2, ..., n:
   1. pos <- |X_i|;
   2. S[:pos) <- S[:pos) ^ X_i;
   3. Y <- Y || S[:pos);
   4. if pos = r, then:
      1. S <- bash-f(S);
      2. pos <- 0.
5. Return Y.

The decrypt Command Input:

• Y in {0, 1}^{8*} -- ciphertext.

Output:

• X in {0, 1}^|Y| -- plaintext.

Steps:

1. commit(TEXT).
2. Parse (Y_1, ..., Y_n) = Split(Y, r).
3. X <- NIL.
4. For i = 1, 2, ..., n:
   1. pos <- |Y_i|;
   2. X <- X || (S[:pos) ^ Y_i);
   3. S[:pos) <- Y_i;
   4. if pos = r, then:
      1. S <- bash-f(S);
      2. pos <- 0.
5. Return X.

The ratchet Command Input:

• None.

Output:

• None.

Steps:

1. T <- S.
2. commit(NULL).
3. S <- S ^ T.

Hashing Hashing is defined by the bash-hash algorithm that depends on the security level l in {128, 192, 256}. The algorithms bashLLL are instances of bash-hash at different security levels: bashLLL = bash-hash[l], LLL = 2l.

The bash-hash Algorithm Parameters:

• l in {128, 192, 256} -- security level.

Input:

• X in {0, 1}^* -- data to be hashed.

Output:

• H in {0, 1}^{2l} -- the hash value.

Steps:

1. Parse (X_1, X_2, ..., X_n) = Split(X || 01, 1536 - 4l).
2. X_n <- X_n || Rep(0, 1536 - 4l - |X_n|).
3. S <- Rep(0, 1472) || Int2Bin(l/4, {64}.
4. For i = 1, 2, ..., n:
   1. S[:1536-4l) <- X_i;
   2. S <- bash-f(S).
5. H <- S[:2l).
6. Return H.

Authenticated Encryption Authenticated encryption is defined by the encryption algorithm bash-prg-ae2561 and the decryption algorithm bash-prg-ae2561-inv. Both algorithms use an automaton denoted as alpha.

The bash-prg-ae2561 Algorithm Input:

• A in {0, 1}^{32*} -- a preamble (|A| <= 480);
• X in {0, 1}^{8*} -- plaintext;
• I in {0, 1}^{8*} -- associated data;
• K in {0, 1}^{32*} -- a key (256 <= |K| <= 480).

Output:

• Y in {0, 1}^|X| -- the ciphertext;
• T in {0, 1}^256 -- the authentication tag.

Steps:

1. alpha.start[256, 1](A, K).
2. Process (X, I):
   1. alpha.absorb(I);
   2. Y <- alpha.encrypt(X);
   3. T <- alpha.squeeze(l).
3. Return (Y, T).

The bash-prg-ae2561-inv Algorithm Input:

• A in {0, 1}^{32*} -- a preamble (|A| <= 480);
• Y in {0, 1}^{8*} -- ciphertext;
• I in {0, 1}^{8*} -- associated data;
• T in {0, 1}^256 -- an authentication tag;
• K in {0, 1}^{32*} -- a key (256 <= |K| <= 480).

Output:

• NIL -- an authentication error, or X in {0, 1}^|Y| -- the decrypted data.

Steps:

1. alpha.start[256, 1](A, K).
2. Process (Y, I, T):
   1. alpha.absorb(I);
   2. X <- alpha.decrypt(Y);
   3. if T != alpha.squeeze(l), then return NIL.
3. Return X.

Bign Algorithms

Preliminaries This specification defines the following algorithms of the Bign family:

• bign-genkeypair -- key pair generation;
• bign-valpubkey -- public key validation;
• bign-sign -- signature generation;
• bign-vfy -- signature verification.

The first two algorithms implement key management, and the last two instantiate the short Schnorr signature scheme over elliptic curves. Algorithms operate at three security levels: l = 128, l = 192 and l = 256. At level l, the private key, public key and signature consist of l/4, l/2 and 3l/8 octets, respectively. The elliptic curves used in Bign satisfy the requirements denoted as bign-curves (see ). Three curves recommended by are defined in .

The bign-curves Elliptic Curves Bign algorithms use elliptic curves of the short Weierstrass form over prime finite fields. A curve is described by the following parameters:

• p: a prime that defines the field FF_p. Elements of FF_p are integers of the set {0, 1, ..., p-1}, added and multiplied modulo p;
• a, b in FF_p: coefficients of the equation E_{a,b}: y^2 = x^3 + a * x + b defining the curve and the set E_{a,b}(FF_p) of its FF_p-rational points. The set E_{a,b}(FF_p) consists of pairs (x, y), x, y in FF_p, satisfying E_{a,b} (affine points) and the point at infinity O.

Points of E_{a,b}(FF_p) are added via the chord-and-tangent rule , turning E_{a,b}(FF_p) into an Abelian group with zero element O. Elliptic curve parameters also describe an affine point G in E_{a,b}(FF_p) with a zero x-coordinate:

• y_G in FF_p: y-coordinate of G;
• q: the order of G in the group E_{a,b}(FF_p).

The point G generates a group GG_q of order q. It consists of points G, 2 G = G + G, 3 G = 2 G + G, ..., (q-1) G and q G = O. In Bign, GG_q always coincides with the entire group E_{a,b}(FF_p). The parameters (p, a, b, y_G, q) are passed to all Bign algorithms. The parameters must satisfy general constraints to ensure a well-defined elliptic curve group, alongside additional requirements for security and efficiency. The full list of requirements, called bign-curves, is as follows.

1. At security level l in {128, 192, 256}: 2^{2l-1} < p, q < 2^{2l}.
2. p and q are primes.
3. p != q.
4. p mod 4 = 3.
5. p^m mod q != 1 for m = 1, 2, ..., 50.
6. 0 < a, b < p.
7. b = Bin2Int(belt-hash(t || seed) || belt-hash(t || seed1)) mod p, where:
   • t = Int2Bin(p, 2l) || Int2Bin(a, 2l);
   • seed in {0, 1}^64 is an initialization parameter for the curve generation algorithm;
   • seed1 = Int2Bin(Bin2Int(seed) + 1, 64).
8. b^{(p-1)/2} mod p = 1, i.e., b is a quadratic residue modulo p.
9. (4 a^3 + 27 b^2) mod p != 0.
10. G = (0, y_G), where y_G = b^{(p+1)/4} mod p.
11. q G = O.
12. p - q < 2^{l+1}.

Let GG_q^* be the set of affine (nonzero) points of GG_q. Points of GG_q^* are encoded as follows.

Point2Bin(P, m):

for P = (x, y) in GG_q^* and positive integer m <= 4l, the string (Int2Bin(x, 2l) || Int2Bin(y, 2l))[:m).

Key Management Algorithms of the Bign family use private keys d in {1, 2, ..., q-1} and public keys Q in GG_q^*. The bign-genkeypair algorithm generates a key pair (d, Q), the bign-valpubkey algorithm validates Q. If necessary, keys are encoded as binary strings Int2Bin(d, 2l) and Point2Bin(Q, 4l).

The bign-genkeypair Algorithm Parameters:

• (p, a, b, q, y_G) -- elliptic curve parameters that describe the group GG_q and its generator G.

Input:

• None.

Output:

• d in {1, 2, ..., q-1} -- a private key;
• Q in GG_q^* -- the corresponding public key.

Steps:

1. d <- {1, 2, ..., q-1}.
2. Q <- d G.
3. Return (d, Q).

The bign-valpubkey Algorithm Parameters:

• (p, a, b, q, y_G) -- elliptic curve parameters.

Input:

• Q = (x_Q, y_Q) -- a public key.

Output:

• 1 if Q is valid, and 0 otherwise.

Steps:

1. If either condition:
   • 0 <= x_Q, y_Q < p;
   • y_Q^2 mod p = (x_Q^3 + a * x_Q + b) mod p;
   is violated, then return 0.
2. Return 1.

Digital Signatures Digital signature algorithms are bign-sign and bign-vfy. The bign-sign algorithm signs messages using a private key d, and bign-vfy verifies signatures using the corresponding public key Q. A message X to be signed is preprocessed by a hash algorithm h that produces 2l-bit hash value H = h(X). To distinguish between different hash algorithms, H is used along with a string OID(h) that uniquely identifies h. This is the DER encoding of the ASN.1 object identifier for h. During the signing process, an ephemeral key pair is generated. This can be done either in probabilistic mode, using bign-genkeypair, or in deterministic mode, by using H and d. The deterministic mode of bign-sign is implemented using the auxiliary bign-genk algorithm.

The bign-genk Algorithm Parameters:

• (p, a, b, y_G, q) -- elliptic curve parameters;
• OID(h) -- an identifier of a hash algorithm h.

Input:

• d in {1, 2, ..., q-1} -- a private key;
• H in {0, 1}^{2l} -- a hash value.

Output:

• k in {1, 2, ..., q-1} -- an ephemeral private key.

Steps:

1. Pick an arbitrary t in {0, 1}^* (t can be the empty string).
2. K <- belt-hash(OID(h) || Int2Bin(d, 2l) || t).
3. r <- H.
4. Parse (r_1, r_2, ..., r_n) = Split(r, 128).
5. For i = 1, 2, ...:
   1. if n = 2, then:
      1. s <- r_1;
   2. if n = 3, then:
      1. s <- r_1 ^ r_2;
      2. r_1 <- r_2;
   3. if n = 4, then:
      1. s <- r_1 ^ r_2 ^ r_3;
      2. r_1 <- r_2;
      3. r_2 <- r_3;
   4. r_{n-1} <- belt-block(s, K) ^ r_n ^ Int2Bin(i, 128);
   5. r_n <- s;
   6. r <- r_1 || r_2 || ... || r_n;
   7. if i mod 2n = 0 and Bin2Int(r) in {1, 2, ..., q-1}, break.
6. k <- Bin2Int(r).
7. Return k.

The bign-sign Algorithm Parameters:

• (p, a, b, y_G, q) -- elliptic curve parameters that describe the security level l, the group GG_q and its generator G;
• h -- a hash algorithm with the identifier OID(h).

Input:

• X in {0, 1}^* -- a message to be signed;
• d in {1, 2, ..., q-1} -- a private key.

Output:

• S in {0, 1}^{3l} -- the signature.

Steps:

1. H <- h(X).
2. If the signing mode is probabilistic, then:
   1. (k, R) <- bign-genkeypair().
3. Else, if the signing mode is deterministic, then:
   1. k <- bign-genk(d, H);
   2. R <- k G.
4. S_0 <- belt-hash(OID(h) || Point2Bin(R, 2l) || H)[:l).
5. S_1 <- Int2Bin((k - Bin2Int(H) - (Bin2Int(S_0) + 2^l)d)) mod q, 2l).
6. S <- S_0 || S_1.
7. Return S.

The bign-vfy Algorithm Parameters:

• (p, a, b, y_G, q) -- elliptic curve parameters that describe the security level l, the group GG_q and its generator G;
• h -- a hash algorithm with the identifier OID(h).

Input:

• X in {0, 1}^* -- a signed message;
• S in {0, 1}^* -- a signature;
• Q in GG_q^* -- a public key.

Output:

• 1, if the signature is valid, and 0 otherwise.

Steps:

1. If |S| != 3l, then return 0.
2. Parse S = S_0 || S_1, where |S_0| = l and |S_1| = 2l.
3. If Bin2Int(S_1) >= q, then return 0.
4. H <- h(X).
5. R <- ((Bin2Int(S_1) + Bin2Int(H)) mod q)G + (Bin2Int(S_0) + 2^l)Q.
6. If R = O, then return 0.
7. t <- belt-hash(OID(h) || Point2Bin(R, 2l) || H)[:l).
8. If S_0 != t, then return 0.
9. Return 1.

Cryptographic Parameters for TLS

Cipher Suites This specification defines the following cipher suites for TLS 1.3 . STB Cipher Suites

Cipher Suite	Value (TBU)	AEAD	Hash
TLS_BELT_CHE256_BELT_HASH	{0xFF, 0x1D}	belt-che256	belt-hash
TLS_BASH_PRG_AE2561_BASH256	{0xFF, 0x1E}	bash-prg-ae2561	bash256

Supporting the TLS_BASH_PRG_AE2561_BASH256 cipher suite is mandated by this specification. Implementation of TLS_BELT_CHE256_BELT_HASH is optional. Both cipher suites assign key_length = 32 and iv_length = 16 (see , Section 7.3). In the TLS record protocol, associated data for authenticated encryption is composed of the opaque_type, legacy_record_version and length fields of the TLSCiphertext structure, 5 bytes in total. When bash-prg-ae2561 is used, the associated data I in {0, 1}^40 is combined with the nonce S in {0, 1}^128 to form the preamble A: A <- S || I || Rep(0, 24). Step 2.1 (alpha.absorb(I)) is skipped during both encryption and decryption. In the belt-che256 and bash-prg-ae2561 algorithms, authentication tags are 8 and 32 bytes long, respectively. An authentication tag T is appended to a ciphertext Y, producing the authenticated ciphertext Y || T saved to TLSCiphertext.encrypted_record. A belt-che256 key must be updated after processing 2^32 TLS records. There are no usage limits for bash-prg-ae2561 keys.

The Diffie-Hellman Protocol The Diffie-Hellman protocol is instantiated as follows.

1. The base cyclic group is a group of elliptic curve points that satisfies the bign-curves requirements (see ).
2. Ephemeral private and public keys are generated using the bign-genkeypair algorithm.
3. Parties validate each other’s public keys using the bign-valpubkey algorithm.
4. Parties compute the shared secret K as follows: K = uV, where u is the ephemeral private key (scalar), V is the ephemeral public key of the opposite party (point on the curve). Curve operations are defined in .
5. The shared secret K, an affine point of the elliptic curve, is encoded as Point2Bin(K, 4l) (see ), where l is the security level.

Elliptic Curves The Diffie-Hellman protocol uses the elliptic curves bign-curve256v1, bign-curve384v1 and bign-curve512v1 defined in . The group identifiers are added to the NamedGroup enumeration (see , Section 4.3.7): The identifiers are used in the supported_groups and key_share extensions.

Digital Signature Algorithms Bign digital signature generation and verification algorithms are instantiated with three combinations of elliptic curve parameters and hash algorithms for message preprocessing. These are the resulting compound algorithms. Digital Signature Algorithms

Compound Algorithm	Elliptic Curve	Hash Algorithm
bign-with-hbelt	bign-curve256v1	belt-hash
bign-with-bash384	bign-curve384v1	bash384
bign-with-bash512	bign-curve512v1	bash512

The digital signature algorithm identifiers are added to the SignatureScheme enumeration (see , Section 4.3.3): The identifiers are used in the signature_algorithms and signature_algorithms_cert extensions.

IANA Considerations This specification requests/registers the following entries to the “TLS Cipher Suites” registry:

Value (TBU)	Description	DTLS-OK	Recommended	Reference
0xFF, 0x1D	TLS_BELT_CHE256_BELT_HASH	N	N	This document
0xFF, 0x1E	TLS_BASH_PRG_AE2561_BASH256	N	N	This document

This specification requests/registers the following entries to the “TLS Supported Groups” registry:

Value (TBU)	Description	DTLS-OK	Recommended	Reference
0xFE01	bign-curve256v1	N	N	This document
0xFE02	bign-curve384v1	N	N	This document
0xFE03	bign-curve512v1	N	N	This document

This specification requests/registers the following entries to the “TLS SignatureScheme” registry:

Value (TBU)	Description	Recommended	Reference
0xFE01	bign-with-hbelt	N	This document
0xFE02	bign-with-bash384	N	This document
0xFE03	bign-with-bash512	N	This document

Security Considerations The security of TLS 1.3 with STB cryptographic parameters depends on the the underlying algorithms. The security-driven design rationale of the belt-block and bash-f algorithms, the core primitives of the Belt and Bash families, is provided in and . Security analysis of belt-hash in shows that under an idealized internal compression function, the collision attack requires approximately 2^{128} operations, and the preimage and second-preimage attacks require at least 2^{192} operations. Both complexities are achievable, although the latter holds only if the resulting preimages are relatively long and of a weakly controlled format. Thus, while the collision security of belt-hash matches that of an ideal (random) 256-bit hash function, its preimage security is lower. However, structural constraints on preimages prevent this lower security bound from being exploited in TLS 1.3. In particular, the Bign digital signature that uses belt-hash for internal hashing is potentially affected at the security level l = 256, where inverting belt-hash in under 2^{256} operations could accelerate signature forgery. But since the forgery attack requires the preimage to be a short string with a highly restricted format, the attack becomes infeasible. The security of belt-che256 is analyzed in . The security guarantees established in that analysis are justified provided that the total number of 128-bit blocks processed by the underlying belt-block cipher is significantly less than 2^{64}. This constraint is directly addressed in the definition of the TLS_BELT_CHE256_BELT_HASH ciphersuite, which requires rekeying belt-che256 after processing 2^{32} TLS records. The bash256 algorithm follows an overwrite mode of sponge-based hash functions . In this mode, security guarantees of bash256-based HMAC--and, in turn, HKDF--can be justified using the approach of , where the underlying bash-f algorithm is treated as a classical compression function, or directly within the framework of sponge-based cryptography (see Section 5.1.3 of ). The security of the Bign signature algorithms, which instantiate the short Schnorr signature, is justified, for example, in . The deterministic mode of bign-sign avoids drawbacks of the usual probabilistic mode, where the weaknesses of RNG / PRNG can yield reuse of ephemeral keys and thus compromise the private key. We recommend using the deterministic mode with a randomly generated t, the deterministic mode with a fixed t, and the probabilistic mode, in this order of preference.

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Informative References Belarusian State University Belarusian State University Belarusian State University Belarusian State University National Center of Information Security of Belarus Belarusian State University Belarusian State University Belarusian State University Pre-proceedings of the 15th Workshop on Current Trends in Cryptology (CTCrypt’2026), pp. 445-470 Belarusian State University Belarusian State University Belarusian State University Belarusian State University Submission to NIST (Round 3) Proceedings of EUROCRYPT 2022, pp. 614-643 New York: Springer Cambridge University Press INDOCRYPT 2004

Recommended Elliptic Curves The following elliptic curves are recommended for the Bign family:

• bign-curve256v1 -- a curve at the security level l = 128;
• bign-curve384v1 -- a curve at the security level l = 192;
• bign-curve512v1 -- a curve at the security level l = 256.

The recommended curves satisfy the bign-curves requirements 1 -- 12 and the following additional requirements:

1. p is the largest suitable prime that does not exceed 2^{2l}.
2. a = p - 3.
3. The numbers q-1 and q+1 both have large prime factors.

Requirements 13 and 14 speed up reduction modulo p and point doubling. Requirement 15 provides protection against Cheon’s attack . This attack is not directly applicable to the Bign algorithms; the purpose of the requirement is to mitigate risks of using the recommended curves outside of Bign. For each security level, the recommended curve was generated as follows:

• 50 curves satisfying the requirements 1 -- 13 were constructed from the smallest possible Bin2Int(seed) values, starting at 0;
• among these curves, the one that yields the maximum of min(gpf(q-1), gpf(q+1)) was chosen.

Here gpf(n) denotes the greatest prime factor of n. The recommended curves are defined below by parameters (p, a, b, y_G, q). Seeds used to construct the curves and factorizations of q-1 and q+1 are also given. Large prime divisors are denoted by r_m, where m is the divisor’s bit length.

The bign-curve256v1 Curve Parameters:

• p = 2^256 - 189;
• a = p - 3;
• b = 5418994543382917476470141667052323987242043847840803114498787\ 1676190519198705;
• y_G = 48835626907528736105417095645674365354469331933013114027389\ 791773001019124371;
• q = 2^256 - 51359303463308904523350978545619999225.

Additional details:

• seed = 0x5E38010000000000;
• q - 1 = 2 * 3 * 5 * 59 * 2707 * 8287 * r_{221};
• q + 1 = 2^3 * 7 * 449 * 31327 * r_{227}.

The bign-curve384v1 Curve Parameters:

• p = 2^384 - 317;
• a = p - 3;
• b = 9305714544225430607690103672579840289571010502599374151660380\ 432967684614892230431863267093750334370523665755520868;
• y_G = 14354597912740189857575301128892105630080584412759834680227\ 804744167703823413075975665088124941253511968357604377681;
• q = 2^384 - 9886438520659958522437788006980660965037549058207958390857.

Additional details:

• seed = 0x23AF000000000000;
• q - 1 = 2 * 3 * 13 * 23 * 1217 * r_{363};
• q + 1 = 2^3 * 5 * 17 * r_{375}.

The bign-curve512v1 Curve Parameters:

• p = 2^512 - 569;
• a = p - 3;
• b = 5693315954776639630120063851326436520321079941853637540614063\ 30518654910952117316642438613460648635268246458383207794163900221\ 6168909012147763529108397200;
• y_G = 88068524280977427056041105285534523859274846872460955723526\ 40065245926924845204146464197290441971825763243615352431448274721\ 410823777569490499978268765629;
• q = 2^512 - 34941104250934712071732195640491222284153110230636945\ 247985077724188765679887.

Additional details:

• seed = 0xAE17020000000000;
• q - 1 = 2^4 * 23 * 79 * 767957 * 4433647 * 103529265929 * r_{419};
• q + 1 = 2 * 3^2 * 5 * 19 * 13997 * 93740551 * 20778982613 * r_{427}.

ASN.1 Definitions

Identifiers To support STB algorithms in X.509 certificates , this specification introduces the following ASN.1 object identifiers:

• bign-with-hbelt, bign-with-bash384 and bign-with-bash512 for the algorithms of the same name;
• bign-pubkey for public keys of the Bign algorithms;
• bign-curve256v1, bign-curve384v1 and bign-curve512v1 for the recommended curves of the same name.

The identifiers are defined as follows:

Public Keys At a security level l, the public key Q is represented as the binary string Point2Bin(Q, 4l). It is described by the following ASN.1 type: In X.509 certificates, the public key is described as follows:

Test vectors

Test Vectors for Belt algorithms

Test Vectors for belt-block

Test Vectors for belt-compress

Test Vectors for belt-che256

Test Vectors for belt-hash

Test Vectors for Bash Algorithms

Test Vectors for bash256

Test Vectors for bash384

Test Vectors for bash512

Test Vectors for bash-prg-ae2561

Test Vectors for Bign Algorithms

Settings Test vectors are constructed using the settings given below.

• Elliptic curve parameters: bign-curve256v1.
• A private key d:

• A public key Q:

• A hashing algorithm h: belt-hash with OID(belt-hash) = 0x06092A7000020022651F51.

Test Vectors for bign-genk

Test Vectors for bign-sign

Test Vectors for bign-vfy

Contributors APMI, Belarusian State University