A-NTS — ANYKS Network Transport Security
A cryptography library and TLS implementation written from scratch against the text of the standards: not a single line from OpenSSL or BoringSSL. Russian national algorithms, the global classics and post-quantum security — in one code base. It will become the main encryption library of AWH.
A complete secure transport, not a bag of ciphers
| Protocol | Standard | Status |
|---|---|---|
| TLS 1.3 | RFC 8446 | complete, both roles, tickets and 0-RTT |
| TLS 1.2 | RFC 5246 | complete, including PSK and tickets |
| DTLS 1.3 | RFC 9147 | flights, windows, record numbers |
| DTLS 1.2 and 1.0 | RFC 6347 | stateless server, HelloVerify |
| QUIC | RFC 9001 | handshake by encryption level, per-level secrets |
| ECH and HPKE | RFC 9849 · 9180 | encrypted client hello: the site name is hidden from observers |
Inside are our own X.509, ASN.1, OCSP, PEM, key codecs and chain trust. The library depends on no third-party part: neither certificate parsing nor big-number arithmetic.
Three worlds of cryptography in one library
Russian GOST
Complete GOST cipher suites for TLS — built in, not a separate provider.
Global classics
Talks to the outside world without caveats: our nodes speak to other servers using the common suites.
Post-quantum
ML-KEM per FIPS 203 and the hybrid TLS group used by browsers. What is intercepted today stays sealed tomorrow.
Connection defaults match browsers: hybrid X25519MLKEM768, AES-256-GCM, ECDSA. The consumer declares GOST suites explicitly — as supported or as the only option; the order of the list is the preference.
GOST against GOST: faster than the reference
A fair comparison needs the same algorithms on both sides. On Astra Linux OpenSSL has the gostprov provider with the very same algorithms, on Elbrus — gost-engine: Kuznyechik against Kuznyechik, signature against signature.
| Operation | A-NTS | Reference | Result |
|---|---|---|---|
| Kuznyechik-MGM | 48.5 | 14.2 | ×3.4 |
| Kuznyechik-CTR | 110.5 | 66.9 | ×1.65 |
| Magma-MGM | 24.2 | 14.6 | ×1.66 |
| Magma-CTR | 50.2 | 45.5 | ×1.10 |
MB/s · Astra Linux 1.8.6, OpenSSL 3.4.0 with gostprov
- GOST R 34.10-2012 signing is 2.6–2.8× faster than the GOST reference, verification 1.8–2.2×, VKO key agreement 2.5×.
- Against OpenSSL's assembly P-256 GOST signing is 2.0–2.3× faster on every test machine, and verification and key agreement are no slower anywhere.
- Streebog is 1.65× faster than the GOST engine on Elbrus and level with its SSE2 variant on x86-64.
On global algorithms — level with OpenSSL
Against OpenSSL on the same machine, with its hardware acceleration. Where the reference is ahead, we say by how much and why.
- ML-KEM-768 is faster than OpenSSL in all three operations — on Apple M4 (0.48 / 0.64 / 0.52 of the reference's time) and on x86-64.
- TLS 1.3 handshake with defaults — level with the reference on M4, FreeBSD and Windows.
- TLS records on M4 — faster than the reference on 1,200-byte packets.
- Random bytes — 6× faster than RAND_bytes on M4 and 11–46× on x86-64.
Where we are still behind
- RSA — 2.2–3.1×: the remainder is in the Montgomery multiplication kernel; assembly is planned.
- Poly1305 on M4 — 1.56× against OpenSSL's hand scheduling.
- AES-GCM on large buffers, x86-64 — 1.27×.
No processor has instructions for Kuznyechik or Streebog, so against hardware-accelerated AES the gap is large; without acceleration it is only 1.3–1.9×.
Native build for Elbrus
The library builds with the lcc compiler and runs on Elbrus-8C2. The x86-64 vector paths are enabled on e2k as well: lcc translates them into its own 128-bit instructions. The reference here is OpenSSL 1.1.1n without e2k assembly, which makes the comparison fairer than on x86 or ARM.
| Operation | A-NTS | OpenSSL | Result |
|---|---|---|---|
| ChaCha20, MB/s | 651 | 122 | ×5.3 |
| ChaCha20-Poly1305, MB/s | 428 | 109 | ×3.9 |
| ECDH P-256, ops/s | 1,469 | 256 | ×5.7 |
| GOST signing, ops/s | 15,820 | 6,186 (gost-engine) | ×2.6 |
| AES-256-GCM, MB/s | 60 | 82 | ×0.73 |
What almost nobody else has
Noise, WireGuard, PQNoise
A complete implementation of the Noise framework with thirteen handshake patterns — a basis for custom secure protocols beyond TLS. WireGuard frames match the reference byte for byte. Post-quantum Noise with a hybrid key mechanism.
The details that break compatibility
Client hello fingerprints, GREASE, certificate chain compression, OCSP stapling, record size limits, certificate timestamps, ALPS. Without them a foreign server simply doesn't answer — so all of it is there.
Checked against the libraries it replaces
Official vectors
- RFC 8448 for the TLS 1.3 handshake
- FIPS 202 and FIPS 203 for SHA-3 and ML-KEM
- BoringSSL rejection vectors for post-quantum
Live exchange
- handshakes with real openssl s_server and s_client
- frozen record corpora from OpenSSL 3.0 and 3.3
- WireGuard frames against the reference
Conformance log
A separate document: requirement of the standard → place in the code → test. A requirement without a test counts as unverified, even if the code looks right.
- Audit in rounds until a round finds nothing. Independent passes over code zones; every finding is pinned by a test so it cannot return.
- Seeded fuzzer. Corrupting any byte of the stream never establishes a connection; findings are reproducible.
- Constant time. Secret operations never branch on secrets.
- Weak is rejected. SHA-1 and MD5 signatures and RSA keys under 2048 bits are not accepted at all.
One CMake and one compiler
OpenSSL's build rests on Perl, BoringSSL's on Go and its own CMake. There is neither here. In a closed environment that matters: the fewer tools to bring in and certify, the faster the system passes acceptance.
Compilers from g++ 10 to g++ 16 and clang — without a single build warning; lcc on Elbrus.
What's next
Performance
Montgomery kernels in assembly for RSA, eight-word kernels for GOST-512 on x86-64 and Elbrus, e2k intrinsics.
Post-quantum signatures
ML-DSA and SLH-DSA, post-quantum HPKE — on par with OpenSSL 4.
For SSH and telecoms
DH over p and g, sntrup761, openssh-key-v1 keys; DTLS 1.3 against OpenSSL 4.1, key logging.
Where it runs: in AWH — HTTPS, WebSocket, QUIC and HTTP/3 with our own code end to end; in Crisper's smart container — file encryption for several recipients and author signatures; in ABS — zero-knowledge storage.