In parallel to mainstream cryptography world, Russia has a strong school of crypto algorithms development, including block ciphers, hash functions, digital signature, etc. There is slow but ongoing trend of harmonizing GOST algorithms usage with the
rest of Internet community. This talk is dedicated to debunking several myths and presenting current state of support in open source projects.
2. 1 What is GOST crypto 2
1 What is GOST crypto
When speaking about contemporary cryptography we are used to common build-
ing blocks. We tend to use AES, SHA-2, RSA or ECDSA without devoting too
much time to select algorithm. They are known to be good, so unless one
has good reason not to use one of them, he uses one of those “recommeded”
algorithms. However several nations have spent significant efforts to develop
their own sets of crypto primitives and high level algorithms to supplement this
well-known set. Russia is one of those countries.
Russian security companies have developed a full set of cryptography algo-
rithms and have published them as GOST standards:
• Symmetric encryption (64-bit and 128-bit ciphers);
• Hash function (256-bit and 512-bit variants);
• Digital signatures (using discrete logarithm problem on elliptic curve).
On top of those primitives they have developed “Recommendations for stan-
dardisation”, which define usage of algorithms in upper-level protocols. This
includes:
• X.509 public key infrastructure;
• CMS Cryptographic Message Syntax (former PKCS #7), extensions to
PKCS #8, #12 file formats;
• TLS Cipher Suites;
• payment applications;
• etc.
2 GOST crypto myths (busting)
2.1 GOST algorithms were developed by FSB
In fact different standards were developed by different parties, with the devel-
opment effort shifting from KGB/FAPSI/FSB towards commercial companies:
• GOST 28147-89 (64-bit symmetric cipher) was developed by KGB, 8th
Department;
• GOST R 34.10-94 (old FF-based digital signature), GOST R 34.11-94 (old
hash function) and GOST R 34.10-2001 (new elliptic curve-based digital
signature) were developed by FAPSI;
• GOST R 34.10-2012 (extension of GOST R 34.10-2001 to use 512-bit
curves), GOST R 34.11-2012 (new hash function), GOST R 34.12-2015
(block ciphers) and GOST R 34.13-2015 (block cipher modes) were devel-
oped by FSB together with OJSC InfoTeCS;
3. 2 GOST crypto myths (busting) 3
• further recommendations for standardisaton are developed by commer-
cial companies under the government of standardisation technical comitee
(TK26).
2.2 GOST algorithms are unsecure and contain trapdoors
and vulnerabilities
It is a typical myth that GOST crypto algorithms were invented by FSB/FAPSI/
KGB to be able to wiretap pedestrian communications and to forge signatures.
Up to now there are no known trapdoors found in the standards. And this
is quite logical for several reasons.
First, pedestrians are not required to use GOST algorithms. They are al-
lowed to use any of existing cryptography solutions unless they are bound by
laws governing government secret data or qualified digital signatures. For all
other cases people can (and will) use any set of cipher.
Second, if authors were to insert a backdoor into the algorithm, it might be
discovered by clever cryptographic researched working for the foreign govern-
ment. And this is exactly what we are trying to be protected from. Keeping
state secrets safe is much more important compared to the theoretical possibility
of reading messages of your pedestrians.
The best known attacks can be found in table 1. As one can see, none of
them are close to be practically implementable.
2.3 National (GOST) crypto is of no concern for the rest of
the world
This is a very well known position, that all nation-wide crypto standards are of
no concern for the rest of the world, because nobody is going to use them.
First, this is not quite true from the position of algorithm diversity. GOST
provides full stack alternative to AES-SHA-ECDSA world. It allows us (soft-
ware developers) to actually check that both standards and their implementa-
tions are not tied to the particular set of algorithms. It allows us to find bugs
and shortcomings in actual crypto libraries implementations, where API or im-
plementation uses particular fixed values or particular properties of algorithms,
preventing future changes of underlying primitives
Second, this approach prevents the flow of ideas generated by Russian com-
munity into worldwide community. Few to name:
• Security Evaluated Standardized Password-Authenticated Key Exchange
(RFC 8133),
• Re-keying for symmetric keys (draft-irtf-cfrg-re-keying),
• Multilinear Galois Mode (draft-smyshlyaev-mgm),
• TLS External re-keying (draft-smyshlyaev-tls12-gost-suites).
4. 3 Existing implementations 4
Tab. 1: Best known attacks on GOST algorithms
Algorithm Type Name Time Mem Notes
GOST 28147-89 symmetric cipher Isobe 2224
264
232
plain / ci-
phertexts pairs
GOST 28147-89 symmetric cipher Dinur, Dunkel-
man, Shamir
(FP)
2192
232
264
plain / ci-
phertexts pairs
GOST 28147-89 symmetric cipher Dinur, Dunkel-
man, Shamir
(Reflection)
2224
236
232
plain / ci-
phertexts pairs
GOST R 34.11-94 hash function Mendel, Pram-
staller, Rech-
berger, Kontak,
Szmidt
2105
collision
GOST R 34.11-94 hash function Mendel, Pram-
staller, Rech-
berger, Kontak,
Szmidt
2192
preimage
GOST R 34.11-2012 hash function Guo, Jean,
Peyrin, Wang
2266
second preimage
for long mes-
sages (> 2259
blocks)
3 Existing implementations
3.1 Commercial implementations
Several companies sell certified closed-source implementations of GOST algo-
rithms in the form of Windows CSP or OpenSSL engine implementations. Few
to name (in the alphabetic order) are CryptoCom, CryptoPro, InfoTeCS, LISSI.
Implementations differ in the featureset, certification level and price.
Additionally CryptCom provides patched version of OpenVPN software and
CryptoPro provides patched Chromium browser version.
3.2 Open Source Software support
Several developers are working on bringing GOST cryptography support into
open source software.
It provides additional tests and generalization to existing libraries. OpenSSL’s
‘gost’ engine is the well known example of being the best way to test that engine-
bound implementations of crypto primitives work correctly.
Having GOST support in existing libraries allows us to replace or supplement
existing proprietary software when working with government-provided informa-
tion.
5. 4 Summary 5
4 Summary
A set of GOST algorithms looks like a promising full-stack alternative to AES/
SHA/RSA/ECDSA-dominated world. Thanks to the recent activity of Russian
engineers both in IETF and IEC/ISO, GOST algorithms are trying to find their
way into international standards, thus opening a possibility for wider adoption
and crypto algorithms diversity. However a lot has to be done for them to
become widely accepted by existing software solutions.
A Current status of GOST support in existing software
A.1 Bright side
The following software provides support for GOST cryptography routines
A.1.1 OpenSSL
For the long time OpenSSL was the primary target of all GOST-related open
source software development. OpenSSL provides only high-level support for
using GOST algorithms in TLS, X.509 and CMS. External ‘gost’ enging provides
low-level algorithms implementation to back the OpenSSL code. For some time
the engine was a part of main tree, but now (since OpenSSL 1.1.0) it was split
to ease maintenance of both parts.
A.1.2 LibreSSL
As LibreSSL is a fork of OpenSSL, it was easy to port OpenSSL’s ‘gost’ engine
code to be a part of LibreSSL library. All GOST-related code is a part of core
library.
A.1.3 GnuTLS
GnuTLS provides mixed support for GOST cryptography. PKI support is pro-
vided upstream, while TLS support is still provided only in form of patches.
GnuTLS maintainers are waiting for the spec to be published as and RFC to
accept the code
A.1.4 libgcrypt
libgcrypt incorporates all GOST primitives support for quite some time. As it is
a popular low-level crypto library, having GOST support allows other developers
to use it to add further support into other cryptography-related software, like
GnuPG, Kleopatra, etc.
A.1.5 xmlsec
xmlsec library provides support for XML signatures according to published
IETF drafts.
6. A Current status of GOST support in existing software 6
A.2 Dark side
Following software does not (yet) provide support for GOST crypto standards,
either because upstream maintainers are reluctant to include support or because
nobody (yet) has worked on adding support for them.
A.2.1 Nettle
Patches for Nettle library are provided, but upstream author did not include
them. Patches are now being tested as a part of GnuTLS library pending future
transition to become a part of Nettle library.
A.2.2 BoringSSL
No work was done yet. However as BoringSSL is another fork of OpenSSL, it
would be easy to port existing code from OpenSSL/LibreSSL.
A.2.3 NSS/Mozilla/Thunderbird
This is quite a sad part of the story. Patches for this software suite exist for
a long time, however upstream maintainers are reluctant to include them for
various reasons.
A.2.4 BIND9
BIND9 has dropped support for GOST DNSSEC because related RFC 5933 is
slowly becoming deprecated because of underlying primitives transition.
A.2.5 IPsec
No open source IPsec software provides support for using GOST ciphers in either
IKEv2 or ESP/AH transformations.