Tracking issue for supporting all variants at the same time

[faern]

I'd like to be able to configure the variant at runtime in my project. So I need the crate to not compile down to just a single variant.

This has been mentioned in other threads. But I felt like it should have it's own tracking issue. Easier to discover, and easier to keep track of work left until v2 can be released.

I think we should play with how this can be implemented once #16 or #20 has been merged. Those are huge API changes, and we probably want to settle on one of those solutions before tinkering with this.

[dkales]

I have started the work on this back in June in https://github.com/dkales/classic-mceliece-rust/tree/feature/correct_rust_feature_use, but this needs to be rebased onto the current v2 changes and it might be better to start from scratch once the API for this is finalized.

I would suggest to either have something like use classic_mceliece_rust::mceliece348864::{keypair,encapsulate,decapsulate}; with all of the variants in their own module, and internally having a mod common; mod internals348864; etc., to keep the shared code down.
Then, based on feature flags, one can enable individual variants when building, but now all of them are supported at the same time.

Another API could look like

use classic_mceliece_rust::parameters::McEliece348864; 
use classic_mceliece_rust::{keypair,encapsulate,decapsulate};

let (sk,pk)  = keypair::<McEliece348864>(&mut rng);

[faern]

If we can solve it with traits and generics I think that looks nicer. Expose a single set of keypair, encapsulate & decapsulate but with a generic specifying the variant. I started toying with that last night as well, but did not get so far, since I focused on finishing the other PR.

If we expose it as separate functions in different modules the API surface becomes much larger and messier IMO. And probably a lot more boilerplate code in the crate itself.

[faern]

Do we even need to feature gate variants? How much more code is added to the library if all are enabled compared to just one? I have not looked at it, but unless shown to be bloaty it feels like unnecessary complexity to feature gate them.

[dkales]

There is a lot of code duplication but it is probably best to do some concrete experiments later.

One problem with the trait + generic approach is that const generics are not at the point yet where one can use associated constants to then define array sizes.

i.e., this does not work without unstable features.

trait McEliece {
  const PUBKEY_BYTES: usize;
  fn keypair() -> [u8; Self::PUBKEY_BYTES];
}

[meisterluk]

For the record: Two years later, this is still not possible. Hence, no trait-based implementation is possible. One can, of course, implement each variant with the same interface, but the equivalence is not represented in the type system then. Since there seems to be little interest, I am not investing the time to implement this as of now.

[gkgoat1]

For the record: Two years later, this is still not possible. Hence, no trait-based implementation is possible. One can, of course, implement each variant with the same interface, but the equivalence is not represented in the type system then. Since there seems to be little interest, I am not investing the time to implement this as of now.

I want to use this crate in the implementation of further systems (I discovered this cryptosystem and thus this crate recently), and do not want to invalidate other crates using Classic McEliece. We could implement this via typenum, though that would be a breaking change.