colfenor / classic-mceliece-rust Goto Github PK

I was wondering if I could get some tips on how to just use the underlying PKE functions (key generation, encryption and decryption) of this library in my project. I have added this library as a dependency in the Cargo.toml of my project as instructed in the README. However, instead of using KEM encapsulation and decapsulation functions, I am interested in using just the PKE functions of the library for instantiation of a PSI protocol I am building. I am relatively new in developing Rust projects, so any tips or hints would be highly appreciated.

This crate is ~10 MiB on crates.io. I have not investigated, but I guess a lot of test data is uploaded. This should not be included.

We have noticed that for the larger key sizes that the library supports, we need to run the functions in a thread with increased stack size. Even if we pass in heap allocated buffers for the key out parameters. My guess is that the library stores the public key on the stack somewhere internally. We have not looked at the code. But it would be great if the caller could somehow tell the library to use the heap more, so it can run in threads with default stack sizes.

This is somewhat related to #12, where we also need a way for the caller to control how the library handles memory buffers.

After we have merged #20 now, what is still open for a version 2.0?

• General Effort to fix all clippy errors?
• #18 should also probably be merged and seems ready?

This is a tracking issue for all steps and related discussions to move our reference-implementation-based infrastructure towards support of RustCrypto defined types and function/method signatures. We want to support a more rust-like API and better integrate with existing cryptographic abstraction in the rust ecosystem.

This is a direct result of discussions in issues #6, #11, and #12.

Hi again. Follow up to #41...

A bunch of people might need or want to still support round3 CME in various programs for quite a while (us included). But the download from crates.io is pretty large, as discovered in the other issue. Would you please consider backporting #42 (probably branch from 68fdbe6 and cherry-pick it in?) and release 2.0.2 with the only difference being that it's smaller?

Thanks for your work on maintaining this crate, and thanks for the 3.0 release! 🥳

I guess there should also be some tests that test the kem interface against KATs, since this would have detected the breakage introduced before.

Happy new year ! Thanks a lot for this suggestion @dkales, today I took some time to go through the current katkem tests we have and I was thinking about implementing the tests for the kem interface against KATs.

However first I need some clarification, the existing test_crypto_kem_api uses keypair_boxed() and the kem designated try_encap() and try_decap() functions which would be assumed to break on a byte number mismatch of CryptoCiphertextBytesTypenum != CRYPTO_CIPHERTEXTBYTES

these kem functions are unrelated/separate concerns in comparison to the described heap feature keypair_boxed(), encapsulate_boxed(), decapsulate_boxed() which currently are also not tested so far ?

Concerning implementing the tests for the kem interface against KATs, I was thinking about options:

• one possibility would be to augment the Testcase struct with separate public key, secret key, ciphertext and sharedsecret bytes for the kem feature, allowing us to run the kem function calls () inside the already existing verify, create_request_file and create_response_file functions without code duplication.

• the other option would be to run the kem_feature tests separately which, would need basically the same other asserts and file I/O functions as the already existing ones, having some code duplication

If possible I would love to hear some feedback on my initial thoughts :)

Using &mut parameters as out parameters is not very idiomatic Rust. It's also easy to misuse. If you instantiate the key arrays and then for some reason miss to call the function that fills them in, the keys are still valid buffers that the programmer can use them, leading to usage of not correct/strong keys at all!

pub fn crypto_kem_keypair(
    pk: &mut [u8; 261120], 
    sk: &mut [u8; 6492], 
    ...
)

A very simple solution is of course to just return the keys:

pub fn crypto_kem_keypair<R: CryptoRng + RngCore>(csprng: &mut R) -> (PublicKey, SecretKey)

But a problem with that is the HUGE size of the PublicKey, and not every developer would want it stored on the stack. But we might also not want to force usage of the heap on the programmer, so it should likely be a choice.

You wanted to talk to us about making pure-rust Classic McEliece possible in Rosenpass ;)

Currently seeing this in the generated documentation is not extremely user friendly:

pub fn crypto_kem_keypair(
    pk: &mut [u8; 261120], 
    sk: &mut [u8; 6492], 
    ...
)

Instead seeing something like the following would be a lot better IMO:

pub fn crypto_kem_keypair(
    pk: &mut PublicKey, 
    sk: &mut SecretKey, 
    ...
)

First of all, the array lengths change depending on which exact variant of the algorithm is chosen, secondly it's very hard to see directly from the type which type of key/data it is. It would be very nice to newtype the keys and have handy helper methods on them. Something like

pub struct PublicKey([u8; crate::CRYPTO_PUBLICKEYBYTES]);

impl PublicKey {
    pub fn as_array(&self) -> &[u8; crate::CRYPTO_PUBLICKEYBYTES] {
        &self.0
    }

    pub fn as_mut_array(&mut self) -> &mut [u8; crate::CRYPTO_PUBLICKEYBYTES] {
        &mut self.0
    }
}

Hi,

First of all, thanks for writing this library! It's great to see pure Rust implementations of some good post-quantum KEM algorithms, especially this one!

I'd love to consume this for a project, in order to not have to pull in all of liboqs to use only Classic McEliece. However, when it comes to cryptography, trust is a major factor. Code has to be audited and the more people who approves of a library the better. In order to minimize the risk of having a security flaw, it should probably be as simple as possible as well. So that leads me to my question: Why implement your own entropy source and corresponding trait (randombytes.rs) instead of pulling in something widely accepted in the ecosystem, such as rand or maybe just getrandom to reduce the number of dependencies?

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.