rusty-saber
A safe pure-rust implementation of the Saber post-quantum scheme.
- Saber is a lattice-based key encapsulation mechanism (KEM)
- The implementation is based on the Saber reference implementation of NIST round 3
- The implementation does not utilize any concurrency techniques (SIMD/threading/…, except maybe auto-vectorization for your CPU)
- It depends on
sha3
as SHA-3 implementation andaes
as AES block cipher (used as RNG) implementation - It passes the 100 testcases of the C reference implementation
- The C reference implementation is included in this distribution since it is used for tests
- It implements the three variants: LightSaber, Saber, FireSaber
- The KEM takes about 25 milliseconds (all three variants) to run on a modern computer
- The implementation is constant-time on software instruction level
- The random number generator is based on AES256 in counter mode
Who should use it?
Anyone, how wants to utilize Saber to negotiate a symmetric key between two parties.
How does one use it?
Add this to your Cargo.toml
:
[]
= "1.0"
To use a specific Saber variant, you need to import it with the corresponding feature flag:
[]
= { = "1.0", = ["lightsaber"] }
Feature flags for the three variants are called lightsaber
, saber
, and firesaber
respectively.
The simple
example illustrates the API:
use ;
use ;
use AesState;
use Error;
How does one run it?
This library comes with two examples:
The pqcgenkat_kem
example implements the classic request/response file structure which is part of the NIST PQC framework.
The different variants can be enabled through feature flags:
saber
is the default variant. Unfortunately, you cannot enable two variants simultaneously.
Is it correct?
Yes. You can run unittests with the following commands:
It compares the output of function calls with its C equivalent.
Besides unittests, you can generate the pqcgenkat_kem
req/rsp files and compare them to the ones generated by the C reference implementation.
We verified that they are equivalent.
Is it fast?
Yes, but it takes roughly 16.2% more runtime than the C implementation. Here, data is always mentioned with clock cycles as unit. The rust implementation has the following clock-cycle count characteristics (the smaller the better):
The C reference implementation has the following clock-cycle count characteristics (the smaller the better):
The tests were done on a Lenovo Thinkpad x260 (Intel Core i5-6200U CPU @ 2.30GHz). In the case of rust, criterion 0.3.5 has been used as given in benches/
and in case of C, the rudimentary code utilizing the TSC register provided with the reference implementation is used. I disabled CPU frequency scaling before running experiments. You can run the benchmark suite yourself with the bench
subcommand, the cref
feature and optionally some variant feature flag:
Where is the source code?
On github.
What is the content's license?
Changelog
- Version 1.0.0: public release
Where can I ask you to fix a bug?
On github.