search

pq-code-package / mlkem-native

High-assurance, high-performance ML-KEM implementation for mobile, pc, and server targets
https://pq-code-package.github.io/mlkem-native/dev/bench/
Apache License 2.0
10 stars 9 forks source link

Clarifying What We Provide in a Release #290

Open potsrevennil opened 2 weeks ago

potsrevennil commented 2 weeks ago

We've set up some criteria for alpha-release, but we've not yet clarify what we actually want to provide as a release.

  1. Do we want to provide an easy-to-use build system which allow users to easily integrate into their projects ?

  2. Do we want to be able to build a static/dynamic-linked library for MLKEM API ?

  3. Do we want to release pre-built static/dynamic-linked library via GitHub release, so that users won't need to bother manually build themselves ?

  4. Any other thoughts ?

@hanno-becker @mkannwischer what's your thoughts on this ?

mkannwischer commented 2 weeks ago

Thanks @potsrevennil - we should indeed have more discussion on how a release should look like and what our goal is.

I think it's none of the options you have suggested. My view is that: mlkem-native (as a part of pq-code-package) is a code package like the XKCP, i.e., we assume that consumers take the source code from our repository in integrate it. (Clarification: There is also something called libXKCP packaging XKCP as a library, but I think we do not intend to do that at the moment.)

That means:

In that sense, a release does not come with any release artifacts other than the snapshot of the current source tree. It merely marks a commit at which a certain set of features has been completed.

The goal for the alpha release is to get mlkem-native into the shape that integration can start for consumers looking for aarch64 or x86 implementations. For a stable release, we want to have assembly formally verified (for at least one platform) and have meaningful CBMC coverage. Plus maybe RV64 support in case there is interest in that. We may want to do another release in between if we can define a reasonable set of features for it.

We are currently investigating integration into liboqs. In case that requires any changes to mlkem-native, I'd like to make those before the alpha release.

@hanno-becker, what do you think about this?

planetf1 commented 1 week ago

I'd agree @mkannwischer - in terms of the code artifacts, but also the docs are clear on the status, sets the right expectation for anyone consuming the library, documents any known limitations/caveats. Much of that is already in the readme. Also we document our security reporting approach (to some extent it is in that we have a file, it says to open a regular issue - is that ok?)

hanno-becker commented 6 days ago

Thanks for raising this @potsrevennil.

I am not yet sold on the idea that mlkem-native is only to be used by taking code, rather than a build artifact. It would seem that for some customers, merely consuming a resulting libmlkem_native.awould be most convenient -- esp. seeing how small the public API is.