Noise Extension: Hybrid Forward Secrecy

[david415]

Are you interested in this feature?

Here's the noise fork by Yawning Angel that has the XXhfs using NewHope-Simple:

• https://github.com/katzenpost/noise

Here's the spec extension:

https://raw.githubusercontent.com/noiseprotocol/noise_spec/41d478d3dd97d77a6695f4d6cf6283e2830e9ca6/extensions/ext_hybrid_forward_secrecy.md

[mcginty]

Yes, I'm interested in adding HFS support.

[dsprenkels]

Hey all, in August/September I will probably have some time to implement this. Can I claim this issue for now?

[mcginty]

@dsprenkels go for it :).

[dsprenkels]

Here's some preliminary notes.

• Implement the latest HFS spec, i.e. the one listed at https://github.com/noiseprotocol/noise_hfs_spec/blob/master/output/noise_hfs.pdf.
• At request of @david415, I will use the Kyber-1024 key encapsulation scheme.
• At first, this scheme will be based on the Rust bindings to the PQClean suite of implementations. https://github.com/PQClean/PQClean from Kannwischer, Rijneveld, Schwabe, Stebila, Wiggers (docs: https://docs.rs/pqcrypto-kyber/0.4.1/pqcrypto_kyber/).
  • Later I intend to implement an optimized version of the Kybers in Rust.
• Moreover, ask the community whether they would like to see a different cryptoscheme, and use that one as well. (In any case announce this project over the mailing list.)
• Everything will be feature gated by a hfs feature, s.t. these changes do not add code/compile bloat.

[dsprenkels]

Hey @mcginty, today I have worked on the HFS support. I have pushed the updates to my hfs branch.

[david415]

I'd like to try out your branch... What is a valid Noise HFS specification string?
This one is not valid:
Noise_XXhfs_25519+Kyber1024_ChaChaPoly_BLAKE2b

[dsprenkels]

Because Trevor's spec did not mention anything about the +-syntax, I have currently implemented the resolving in a way that you have to specify the KEM separately in the builder. Let me give an example:

let params: NoiseParams = "Noise_NNhfs_25519_ChaChaPoly_SHA256".parse().unwrap();
let mut h_i = Builder::new(params.clone())
    .kem(KemChoice::Kyber1024)
    .build_initiator()
    .unwrap();

In this case, the resolver is the default resolver (not ring). Btw. don't forget to enable the hfs and pqclean_kyber1024 features.

I agree that, given the fact that Kyber1024 is currently the only supported KEM, explicitly choosing it might feel a bit pointless. Maybe this is something to be updated.

Note to self: Ask the community about this.

[david415]

Hi all. I'm looking forward to this feature getting landed. No hurry I'm just saying that I'm looking forward. Cheers!

[mcginty]

This is now merged in master.