ntrust-native

A safe pure-rust implementation of the NTRU post-quantum scheme.

Who should use it?

Anyone, how wants to use the NTRU scheme to negotiate a key between two parties.

How does one use it?

Add this to your Cargo.toml: toml [dependencies] ntrust-native = "1.0"

To use a specific NTRU variant, you need to import it with the corresponding feature flag:

toml [dependencies] ntrust-native = { version = "1.0", features = ["ntruhrss701"] }

The simple example illustrates the API: ```rust use ntrustnative::AesState; use ntrustnative::{cryptokemdec, cryptokemenc, cryptokemkeypair}; use ntrustnative::{CRYPTOBYTES, CRYPTOCIPHERTEXTBYTES, CRYPTOPUBLICKEYBYTES, CRYPTO_SECRETKEYBYTES};

use std::error;

fn main() -> Result<(), Box> { let mut rng = AesState::new(); let mut pk = [0u8; CRYPTOPUBLICKEYBYTES]; let mut sk = [0u8; CRYPTOSECRETKEYBYTES]; let mut ct = [0u8; CRYPTOCIPHERTEXTBYTES]; let mut ssalice = [0u8; CRYPTOBYTES]; let mut ssbob = [0u8; CRYPTO_BYTES];

cryptokemkeypair(&mut pk, &mut sk, &mut rng)?; cryptokemenc(&mut ct, &mut ssbob, &pk, &mut rng)?; cryptokemdec(&mut ssalice, &ct, &sk)?;

asserteq!(ssbob, ss_alice);

Ok(()) } ```

How does one run it?

This library comes with two examples:

bash $ cargo run --example simple

The output annotates messages with Alice/Bob to illustrate which data is processed by which party. The katkem example implements the classic request/response file structure which is part of the NIST PQC framework.

bash $ cargo run --example katkem PQCkemKAT_935.req PQCkemKAT_935.rsp $ cargo run --example katkem PQCkemKAT_935.rsp

The different variants (ntruhps2048509, ntruhps2048677, ntruhps4096821, ntruhrss701) can be enabled through feature flags:

bash $ cargo run --example katkem --features ntruhrss701 -- PQCkemKAT_1450.req PQCkemKAT_1450.rsp

ntruhps2048509 is the default variant. You cannot enable two variants simultaneously.

How fast is it?

All data uses clock cycles as unit. The rust implementation has the following clock-cycle count characteristics (the smaller the better):

complete KEMkeypairencdec
ntruhps204850919,980,85514,105,680472,9091,122,414
ntruhps204867727,478,93924,077,519895,9302,333,079
ntruhps409682142,083,12536,882,7831,487,4013,367,818
ntruhrss70132,433,99328,506,984828,1622,919,074

The C reference implementation has the following clock-cycle count characteristics (the smaller the better):

complete KEMkeypairencdec
ntruhps204850915,912,90012,139,200811,6511,812,650
ntruhps204867728,911,50022,233,6001,520,6403,668,860
ntruhps409682141,914,80032,138,3002,089,3505,908,570
ntruhrss70128,966,60023,134,7001,368,2703,462,640

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, Google's benchmark with PFM support and disabled CPU frequency scaling. Our summary is that both implementations have comparable runtime. rust is a little bit slower (but uses many copy operations for type safety you could replace with unsafe {} code). You can run the benchmark suite yourself with the bench subcommand and optionally some variant feature flag:

bash $ cargo bench --features ntruhrss701

Where is the source code?

On github.

What is the content's license?

MIT License

Changelog

Where can I ask you to fix a bug?

On github.