Short answer. Kupyna is a Ukrainian cryptographic hash function standardized as DSTU 7564:2014. In a qualified electronic signature (QES) it plays the same role that DSTU GOST 34.311-95 used to play: it compresses the document into a short digest, which is what actually gets signed with a DSTU 4145 key. Kupyna is designed on modern cryptographic principles and is gradually replacing GOST in the national systems. In DSTUcrypt it is supported out of the box — enabled with a single option, digest:'kupyna-256'.
Why a signature needs a hash function at all
An electronic signature never signs the whole document directly — that would be slow and mathematically awkward. Instead, the document is first run through a hash function, which turns a file of any size into a short, fixed-length digest (256 bits for Kupyna-256). It is this digest that gets signed with the private key under DSTU 4145.
The strength of a signature therefore depends on two algorithms at once: the signature scheme itself and the hash function. If someone learns to craft two different documents with the same digest (a collision), an attacker can transplant a valid signature from one document onto another. That is why an obsolete hash function in a signature scheme has to be replaced sooner or later — even if the signature algorithm itself is still sound.
Where Kupyna came from
Until 2014, Ukrainian QES relied on the DSTU GOST 34.311-95 hash function — an adapted interstate standard from the Soviet-era cryptographic school, built on the GOST 28147-89 block cipher. It was a solid design for its time, but 1990s constructions were never meant to withstand modern cryptanalysis: published research has shown that the real-world strength of GOST 34.311-95 is below its nominal level.
In 2014, Ukraine adopted its own modern standard — DSTU 7564:2014 Kupyna (in force since 2015). It was developed by Ukrainian cryptographers using approaches proven in the international SHA-3 competition: at its core are AES-like transformations with a large cryptographic security margin. The standard defines variants with different digest lengths — Kupyna-256, the one most used in QES, plus Kupyna-384 and Kupyna-512 for tasks that need a longer hash.
Kupyna vs GOST 34.311-95
| Kupyna (DSTU 7564:2014) | DSTU GOST 34.311-95 | |
|---|---|---|
| Year standardized | 2014 (in force since 2015) | 1995 |
| Digest length | 256 / 384 / 512 bits | 256 bits |
| Construction | modern, based on AES-like transformations (SHA-3 generation) | built on the GOST 28147-89 block cipher |
| Known cryptanalysis | no published attacks that threaten its practical strength | shown to have real strength below the nominal level |
| Status in national systems | target standard, being rolled out | kept for compatibility; still what government validators accept today |
Kupyna, Kalyna, DSTU 4145: how the standards work together
The modern Ukrainian cryptographic stack is three standards with distinct roles:
- DSTU 4145-2002 — the electronic signature itself, on elliptic curves. This is what your QES key is.
- DSTU 7564:2014 Kupyna — the hash function: it produces the document digest to be signed.
- DSTU 7624:2014 Kalyna — the block cipher: it encrypts the data itself (for example, in CMS EnvelopedData).
An important practical consequence: Kupyna does not require a new key. The key is a DSTU 4145 key; the hash function is merely paired with it on each signing operation. So migrating from GOST 34.311 to Kupyna means changing a single signing parameter — not reissuing keys for every user.
Why government validators still accept GOST — and what that means for you
Migrating a large government infrastructure to a new standard is a gradual process. As of today, government validators (the Diia app, the central CA (CZO)) accept the pair "DSTU 4145 signature + DSTU GOST 34.311-95 hash" — which is exactly why it remains the safe default for documents headed into government systems.
For an integrator this translates into a simple strategy: sign with GOST 34.311 by default and enable Kupyna explicitly wherever the receiving side already supports it (internal document workflow, B2B exchange, your own verification systems). A solution that supports both hashes is ready for today's requirements and for the future transition alike.
How this works in DSTUcrypt
In DSTUcrypt — a service of embeddable QES widgets — both hash functions are available out of the box, and all cryptography runs in the user's browser (WebAssembly): the key and password never reach your server or ours. Choosing the hash is a single option:
signing with the Kupyna hash — one option
import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';
const signer = await embed('sign', { mount: 'modal' });
const { signature } = await signer.sign(fileBytes, {
format: 'CAdES-T',
digest: 'kupyna-256', // Kupyna DSTU 7564; without this option — GOST 34.311
});
Along with the hash, the service automatically picks the matching DSTU 4145 signature algorithm — no extra configuration. This works across all 16 supported formats, including XML signatures: XAdES with Ukrainian DSTU 4145 keys supports both GOST 34.311 and Kupyna-256. And once government systems switch to Kupyna, changing the default in your integration is one line of code — no rebuilds or updates on your side.
Why this is rare. Most web crypto libraries either know nothing about Ukrainian standards or implement only the old GOST. DSTUcrypt runs on a crypto core — a battle-tested native C/C++ library compiled to WebAssembly that has served Ukrainian PKI for years. It is a production solution supporting the full stack of updated national standards: Kupyna, Kalyna, DSTU 4145.
For a step-by-step guide with examples for every format, see "How to sign a document with a QES using the Kupyna hash in the browser".
Frequently asked questions
Do I need a new QES key to sign with Kupyna?
No. A QES key is a DSTU 4145 signing key, and Kupyna merely replaces the hash function paired with it. If your key supports modern algorithms, it is enough to enable the digest:'kupyna-256' option when signing.
Will a signature with the Kupyna hash be accepted by Diia and government registries?
Today, government validators (Diia, the central CA (CZO)) accept the pair "DSTU 4145 signature + DSTU GOST 34.311-95 hash", so that pair is the safe default. Kupyna should be enabled explicitly wherever the receiving side supports it. Once government systems switch to Kupyna, the change comes down to one line of code.
How does Kupyna differ from Kalyna?
Kupyna (DSTU 7564:2014) is a hash function: it compresses a document into a control digest for signing. Kalyna (DSTU 7624:2014) is a block cipher: it encrypts the data itself. They are two different standards that, together with the DSTU 4145 signature, make up the modern Ukrainian cryptographic stack.
Is GOST 34.311-95 considered broken?
No practical attacks on the full GOST 34.311-95 have been demonstrated, but published cryptanalytic work shows that its real strength is below the nominal level, and the 1990s construction itself falls short of modern requirements. That is exactly why Ukraine adopted a modern standard — DSTU 7564:2014 Kupyna.
Read next
- How to sign a document with a QES using the Kupyna hash in the browser: a practical guide
- Electronic signature formats: CAdES, PAdES, XAdES, ASiC — which to choose
- The dangers of pure-JS cryptography: timing attacks and key recovery from signatures
QES with Kupyna on your site — in 10 minutes
Ready-made widgets for signing, verification and encryption under DSTU standards. The key and password never leave the user's browser. Every new domain gets 7 days free.
Live demoHow to integrate