# Tongsuo cryptographic library: TLCP, post-quantum algorithms, and native integration

> Tongsuo is a C cryptographic library for applications that need Chinese commercial cryptography, TLS protocol extensions, zero-knowledge proofs, homomorphic encryption, and post-quantum algorithms. Its main adoption cost is native build integration and responsibility for selecting the correct protocol and algorithm configuration.

**Tongsuo-Project/Tongsuo** — 铜锁/Tongsuo is a Modern Cryptographic Primitives and Protocols Library

- Repository: https://github.com/Tongsuo-Project/Tongsuo
- Website: https://www.tongsuo.net
- Stars: 1,547 · Forks: 264
- Language: C
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tongsuo-project-tongsuo

## Tongsuo targets protocol requirements that ordinary TLS deployments may miss

Tongsuo solves a specific infrastructure problem: providing cryptographic primitives and secure communication protocols as a native library, rather than leaving those operations entirely to an application or platform service. The README identifies storage, networking, key management, and privacy computing as target scenarios. The stated goal is to protect confidentiality, integrity, and authenticity across data transmission, use, and storage. That makes the project relevant to software that must control protocol details, certificate handling, or algorithm selection at build time.

The project is particularly relevant to Chinese commercial cryptography deployments. It documents support for SM2, SM3, SM4, and ZUC, along with TLCP, described as a dual-certificate protocol based on GB/T 38636-2020. It also documents RFC 8998, identified as TLS 1.3 with a Chinese commercial cryptography single-certificate model. This combination is materially different from treating SM algorithms and conventional TLS as interchangeable. The certificate model and protocol negotiation matter.

Tongsuo also includes newer cryptographic areas. The README lists Bulletproofs range proofs, Bulletproofs R1CS, EC-ElGamal, Paillier, ML-KEM(Kyber), ML-DSA(Dilithium), and SLH-DSA(SPHINCS+). The breadth is useful for research systems and applications with explicit requirements, but it also increases the configuration and review surface. A library supporting many algorithms does not automatically mean that one binary should enable every algorithm in every deployment.

## The library architecture exposes algorithms, protocols, providers, and examples

The repository layout shows that Tongsuo is a substantial C library rather than a command-line application. The `crypto/`, `providers/`, `engines/`, and `ssl/` directories indicate separate areas for cryptographic implementation, providers, engines, and secure communication. Public headers are under `include/`, while `apps/` and `util/` contain executable components. The `test/` directory and `.clusterfuzzlite/` directory indicate that testing and fuzzing infrastructure are part of the repository structure.

The README describes Tongsuo as providing both algorithms and protocols. In practical terms, the library can serve code that needs a primitive such as SM4 or RSA, while the SSL portion covers communication behavior such as TLS, TLCP, certificate compression, and QUIC. The documentation also links to a `README-QUIC.md` file and separate material for delegated credentials, but the cleaned README does not provide a complete API walkthrough for either feature. An evaluator should therefore inspect the exact headers, examples, and release documentation for a required feature instead of assuming that every listed capability has the same interface or maturity.

The `examples/` directory includes a basic `sm.c` example and an `examples/perf/` directory. This is a useful sign that the project provides source-level entry points for learning, but it is not a substitute for an application-specific integration guide. The project also ships `Configure`, `config`, and `Configurations/`, indicating a configure-based build with selectable features. Native linking, ABI expectations, and certificate provisioning therefore belong in the adoption plan.

## Building Tongsuo and enabling a first library integration

The README documents a source build rather than a package-manager installation. On Linux, macOS, or similar systems, the documented prerequisites are `make`, Perl 5 with `Text::Template`, a C compiler, and the C library. The basic build installs headers, library files, and Tongsuo binary programs. For Windows, the documented configure and build sequence uses Perl, `nmake`, and `nmake install`.

A first native build can follow the repository's documented commands. The prefix determines the installation destination, and the reader should expect the installed headers and libraries to be placed below that destination.

```bash
./config --prefix=/path/to/install/dir
make
make install
```

The README also provides separate installation targets for narrower deployment cases. `make install_runtime_libs` installs library files only, while `make install_dev` is intended when application development also needs headers. These targets are useful because an application image may not need the command-line programs or development files that a full installation contains.

```bash
make install_runtime_libs
```

```bash
make install_dev
```

For an isolated build directory, the documented approach is to enter `tongsuo-build` and run the source tree's `config` script with a destination prefix. This keeps generated build artifacts outside the source checkout, but the destination remains an operator-selected path.

```bash
cd tongsuo-build
/path/to/Tongsuo/source/config --prefix=/path/to/dest
make
make install
```

To enable a protocol or algorithm family, the README describes `enable-xxx` options and gives `enable-ntls` as the TLCP example. It gives `no-rsa` as the corresponding example of disabling RSA. The README does not document the complete option matrix, so the exact configure flag for a deployment requirement must be checked in the repository's configure output or documentation before release packaging.

## TLCP and RFC 8998 require an explicit certificate decision

The protocol distinction is the main integration decision for Tongsuo deployments involving Chinese cryptography. TLCP is documented as a dual-certificate protocol, while RFC 8998 is documented as TLS 1.3 with a Chinese commercial cryptography single-certificate model. These are different protocol and certificate arrangements. An application that enables `enable-ntls` is not simply selecting a different cipher string inside an otherwise unchanged TLS configuration.

The README links to dedicated TLCP and TLS 1.3 material, but it does not provide a complete certificate-generation, trust-store, or server-client configuration tutorial. It also does not state whether a particular deployment should use TLCP or RFC 8998. That choice depends on the certificate model required by the counterpart system and the applicable standard. Teams should not invent certificate assumptions from the algorithm list alone.

For applications that already rely on a web server or gateway, the README lists Angie as an open-source application and explicitly says it recommends Tongsuo users prioritize Angie to enable Tongsuo functionality. It also lists Apache APISIX and Tengine. This indicates that Tongsuo can be introduced through a server integration path, not only by linking an application directly. The repository does not document the configuration syntax for these integrations in the README, so the integration-specific documentation must be consulted before selecting a deployment model.

## Post-quantum, privacy, and zero-knowledge support still need narrow validation

The algorithm catalog makes Tongsuo relevant to systems beyond conventional certificate-based TLS. The README lists ML-KEM(Kyber), ML-DSA(Dilithium), and SLH-DSA(SPHINCS+) under post-quantum cryptography. It lists EC-ElGamal and Paillier under homomorphic encryption, and Bulletproofs range and Bulletproofs R1CS under zero-knowledge proofs.

Each category introduces a different protocol contract. A post-quantum signature algorithm does not replace certificate issuance by itself. A homomorphic encryption implementation does not define the application data model or circuit that will operate on ciphertext. A zero-knowledge proof library does not by itself provide the statement format, proving key lifecycle, or verifier integration used by an application. The README names the capabilities, but it does not give enough API or deployment detail to treat them as interchangeable drop-in replacements.

This is where Tongsuo's breadth becomes a review burden. An adoption team should identify the exact primitive, parameter set, serialization format, error behavior, and peer compatibility required by the system. If the application only needs ordinary TLS and has no Tongsuo-specific protocol requirement, the additional algorithms may add build and audit work without delivering a needed feature.

## Tongsuo carries native-build and upgrade responsibilities

Tongsuo is not archived, and the repository's last push was on 2026-10-15. The README also links to GitHub releases, with 8.5.0 listed as the latest release on 2026-09-30. That is a recent maintenance signal, but it does not remove upgrade work. A native C library integration can affect the application build, container image, linker configuration, and possibly the application binary when its headers or libraries change.

The README provides selective installation targets, which can reduce runtime image contents, and separate documentation files such as `README-FIPS.md`, `README-PROVIDERS.md`, and `README-QUIC.md`. Those files indicate that provider, FIPS, and QUIC behavior are areas that may need separate review. The README does not describe the supported upgrade path, ABI policy, compatibility matrix, or rollback procedure. Those omissions matter for production software.

The license is Apache-2.0. That identifies the repository's stated licensing model, but software teams still need to review the license text, notices, dependency terms, and their own distribution obligations. Tongsuo's certification statements also do not replace an application's protocol review, certificate lifecycle review, or security testing.

## A platform TLS stack is a simpler alternative when Tongsuo-specific features are unnecessary

The practical alternative for many applications is the platform or operating-system TLS stack rather than compiling Tongsuo. That approach keeps cryptographic implementation and protocol maintenance outside the application's native build, but it only works when the required algorithm and protocol set is already exposed by that stack. It will not satisfy a requirement for TLCP, RFC 8998 with the documented certificate model, Tongsuo ZKP, or one of the listed homomorphic and post-quantum features unless the platform offers those capabilities.

The difference is therefore architectural. Tongsuo gives a C project direct access to a broad set of algorithms, TLCP, QUIC APIs, delegated credentials, certificate compression, and privacy-oriented primitives. A platform TLS stack gives an application a smaller integration surface, with platform-specific configuration and update ownership. The README does not document a direct performance or security superiority comparison, so it would be unsupported to claim that either approach is universally faster or safer.

Tongsuo is the wrong tool when the application needs only standard TLS and cannot justify native cryptographic-library ownership. It is the right candidate when the protocol or algorithm requirement is specific enough to justify that ownership and the team can verify the relevant certificate, provider, build, and compatibility details.

## Conclusion

Adopt Tongsuo when an application specifically needs SM2, SM3, SM4, TLCP, RFC 8998, QUIC, ZKP, homomorphic encryption, or the listed post-quantum algorithms. Do not choose it merely because an application needs ordinary TLS unless the team is prepared to own a native cryptographic-library integration. Verify first that the required protocol, algorithm, platform build, and certificate model are supported in the release being deployed.

## FAQ

### How do I install Tongsuo on Linux?

The README documents configuring the source tree with `./config --prefix=/path/to/install/dir`, followed by `make` and `make install`. It requires `make`, Perl 5 with `Text::Template`, a C compiler, and the C library.

### How do I enable TLCP in Tongsuo?

The README identifies `enable-ntls` as the configure option that enables TLCP. It does not provide the complete certificate and deployment configuration for a TLCP application.

### Which post-quantum algorithms does Tongsuo support?

The README lists ML-KEM(Kyber), ML-DSA(Dilithium), and SLH-DSA(SPHINCS+) under post-quantum cryptography. It does not document application integration steps for those algorithms in the README.

## Sources

- [License: Apache-2.0](https://github.com/Tongsuo-Project/Tongsuo/blob/master/LICENSE)
- [Project website](https://www.tongsuo.net)
- [README](https://github.com/Tongsuo-Project/Tongsuo/blob/master/README.md)
- [Releases](https://github.com/Tongsuo-Project/Tongsuo/releases)
- [Tongsuo-Project/Tongsuo on GitHub](https://github.com/Tongsuo-Project/Tongsuo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tongsuo-project-tongsuo