Add hfs kyber nist round three

[david415]

Okay. This is ready for review. I got rid of all the .unwrap() calls except for the two located in the "generate" method:

    /// Generate a new private key.
    fn generate(&mut self, _rng: &mut dyn Random) {
        // Oqs uses their own random generator
        let kemalg = kem::Kem::new(kem::Algorithm::Kyber1024).unwrap();
        let (pk, sk) = kemalg.keypair().unwrap();
        self.alg = kemalg;
        self.pubkey = pk;
        self.privkey = sk;
    }

Should I change the function signature or keep it as is?

[david415]

Note that until open-quantum-safe/liboqs#909 and cloudflare/circl#213 are resolved we should NOT merge this pull-request; The issue is that the liboqs Kyber is not compatible with Cloudflare's Golang Circl library's Kyber. I want them to be compatible because I'm using them both in my software. Obviously they should be compatible, but alas they are not.

That having been said, please do review this PR! I will make requested corrections and maintain this branch until the above compatibility issues are resolved. Thanks and cheers!

[bwesterb]

As Thom pointed out, the current Rust crate implements Round 2 Kyber, whereas Circl has been updated to Round 3 Kyber. You'll have to wait for a release of libels or use an older version of Circl. https://github.com/katzenpost/noise/issues/9#issuecomment-778034278

Note that it is quite possible there will be more breaking changes to Kyber in the future.

[david415]

As Thom pointed out, the current Rust crate implements Round 2 Kyber, whereas Circl has been updated to Round 3 Kyber. You'll have to wait for a release of libels or use an older version of Circl. katzenpost/noise#9 (comment)

Note that it is quite possible there will be more breaking changes to Kyber in the future.

@bwesterb I'm hoping that the maintainer of snow @mcginty will allow us to just use the main branch of the oqs rust crate for the time being until a new version of the oqs crate is released. Or better yet, a specific commit id from the main branch that way it won't just break unexpectedly one day.

[david415]

I've confirmed that this branch can interoperate with the Katzenpost fork of Go noise:
https://github.com/katzenpost/noise

[mcginty]

As Thom pointed out, the current Rust crate implements Round 2 Kyber, whereas Circl has been updated to Round 3 Kyber. You'll have to wait for a release of libels or use an older version of Circl. katzenpost/noise#9 (comment)
Note that it is quite possible there will be more breaking changes to Kyber in the future.

@bwesterb I'm hoping that the maintainer of snow @mcginty will allow us to just use the main branch of the oqs rust crate for the time being until a new version of the oqs crate is released. Or better yet, a specific commit id from the main branch that way it won't just break unexpectedly one day.

Given that Kyber support is still an experiment hidden behind a non-default feature flag, this seems fine.

[david415]

@mcginty Alright I've made the corrections you specified but now I'm wondering if you can help me figure out why the build fails:

user@computer:~/code/snow$ cargo build --features nist3_kyber1024
warning: panic message contains braces
   --> src/params/patterns.rs:580:48
    |
580 |         "handshake messages contain one of the {{'e1', 'ekem1'}} tokens, but not the other",
    |                                                ^^             ^^
    |
    = note: `#[warn(non_fmt_panic)]` on by default
    = note: this message is not used as a format string, but will be in a future Rust edition
help: add a "{}" format string to use the message literally
    |
580 |         "{}", "handshake messages contain one of the {{'e1', 'ekem1'}} tokens, but not the other",
    |         ^^^^^

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.16s

[mcginty]

@mcginty Alright I've made the corrections you specified but now I'm wondering if you can help me figure out why the build fails:

user@computer:~/code/snow$ cargo build --features nist3_kyber1024
warning: panic message contains braces
   --> src/params/patterns.rs:580:48
    |
580 |         "handshake messages contain one of the {{'e1', 'ekem1'}} tokens, but not the other",
    |                                                ^^             ^^
    |
    = note: `#[warn(non_fmt_panic)]` on by default
    = note: this message is not used as a format string, but will be in a future Rust edition
help: add a "{}" format string to use the message literally
    |
580 |         "{}", "handshake messages contain one of the {{'e1', 'ekem1'}} tokens, but not the other",
    |         ^^^^^

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.16s

That's a benign warning.

Your build is failing on windows because of liboqs (I imagine it was failing before your change as well - I just enabled Windows CI a few hours ago):

https://github.com/mcginty/snow/pull/106/checks?check_run_id=1897933780#step:4:661

[BlackHoleFox]

The current issue the CI failures are seeing is due to bindgen. There's an issue similar to it here. Maybe we could try pointing it at the runner's clang installation in the environment variable?

[david415]

The current issue the CI failures are seeing is due to bindgen. There's an issue similar to it here. Maybe we could try pointing it at the runner's clang installation in the environment variable?

I have no idea how to do that.

[dsprenkels]

This is dangerous, in the context of publishing on https://crates.io. crates.io does not allow dependencies that are pulled from a Git repo. (See also RFC 2141.) There has to be a crate here.

[david415]

Right. Can we convince the maintainers of the oqs crate to adopt a reasonable versioning scheme which progresses faster than every 6 months?

[david415]

I'd really rather not have to fork oqs and fork snow. But the way things are now it's looking like I'm going to have to in order to actually do a "cargo publish". So sad.

[mcginty]

Closing, since it's aged long enough.