cryspen / libcrux Goto Github PK

          The top level should probably expose something like this.

With all the warnings in here. We should make sure the top level APIs are done well and offer these different options, and then drop the functions here that are not necessary.
You can do that here, or file a follow-up.

Originally posted by @franziskuskiefer in #63 (comment)

In the macOS CI image, the command

cargo build --verbose --target aarch64-apple-darwin

sometimes, but not always, results in a whole bunch of warnings and error.

Functions such as simd128_support, simd256_support, etc. should do detection based on information obtained at runtime and not use build-time cfg flags.

          `libcrux_platform` checks for `avx` in simd128_support() besides `avx2` in simd256_support(), AFIAK both aren't supported in x86 32-bit processors but can be enabled with `-m32` mode on x64 targets

Originally posted by @mamonet in #73 (comment)

Also: #73 (comment)

Not all the code we have in libcrux is verified (e.g. SHA-2 and x25519 from libjade) and we may want to add other partially-verified code in the future. Our policy is that unverified code will never be exposed in the libcrux API. We may want to better document the status of various implementations in a STATUS.md file or something.

Update the CI

• add merge queues
• add rust fmt checks
• add individual jobs for the sys libraries.

Platform support

• macOS x64
• macOS aarch64 (builds only)
• iOS aarch64 (builds only)
• Windows x86
• Windows x64
• Linux x64
• Linux x86
• Linux aarch64
• Android aarch64
• wasm-32

Ergonomics & Maintainability

• Pull out common things like setup into reusable workflows

There are some CI improvements esp. for 32-bit in #21.

The uniform_sampler_mean_and_variance and binomial_sampler_mean_and_variance tests in sampling.rs in the Kyber specification fail intermittently, perhaps due to an issue in the randomness provided by proptest.

Update the build to

• #46
• #47
• #48
• add basic CI support to ensure all of this is working

Some open ToDos on branch franziskus/hacl-sys

• consistent naming of sys crates (libjade-sys, libcrux-hacl-sys, libcrux-platform, ... ?)
• consistent version numbers across crates
• fix all crates to the right version ("=0.0.1")
• use new libcrux-hacl-sys functions in hacl module with hardware detection from libcrux-platform
• use functions from hacl module in libcrux
• #93

Platform support

• macOS (arm64, x64)
• Windows (x64, x86)
• Linux (x64, x86)

Platform support for follow ups

• #90
• #91
• wasm (#10)
• Windows (arm64)
• #92

• #28
• #29

There's a drafty version in #21.

          Let's add a note to the readme that in order to build this the libclang path needs to be set correclty.

Originally posted by @franziskuskiefer in #57 (comment)

          How much work would it be to sidestep evercrypt for AES GCM?

That's the only one that doesn't have a HACL API.

Originally posted by @franziskuskiefer in #63 (comment)

• Rewrite sample_from_uniform_distribution to return early within the loop once that's better supported in hax
• Remove the spurious let binding to MONTGOMERY_R in montgomery_reduce once hacspec/hax#332 is fixed.

When Kyber is added in #17, add a Kyber HPKE ciphersuite as well as a hybrid ciphersuite (using https://datatracker.ietf.org/doc/html/draft-westerbaan-cfrg-hpke-xyber768d00).

https://github.com/formosa-crypto/libjade/tree/main/src/crypto_kem/kyber

• ref #23
• #30

• ensure the build and tests are working
• add the target to CI

make hardware feature detection complete and use it instead of the config flags

Add WASM compile target with HACL WASM code.

The following values are usually set in sys/hacl/config/config.h. We need to set them depending on the platform we are building for.

• TARGET_ARCHITECTURE
• HACL_CAN_COMPILE_UINT128
• HACL_CAN_COMPILE_VALE
• LINUX_NO_EXPLICIT_BZERO

Once the code in the Kyber reference implementation starts to stabilize, document everything in it carefully.

We should test our implementations against the following:

• https://github.com/post-quantum-cryptography/KAT/tree/v0.0.1/MLKEM
• https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/eu9Od-hg4Cg
• https://github.com/C2SP/CCTV/tree/main/ML-KEM
  • Intermediate values
  • Bad encapsulation keys
  • Unlucky NTT sampling vectors
  • strcmp vectors
  • Accumulated pq-crystals vectors

• #19
• #27
• #9
• #25
• #26
• #31

• ensure the target is working
• add the target to CI

linking fails right now

The kem APIs currently use Vec<u8>s for inputs and outputs. This, along with the fact that they allow for different algorithms to be selected, necessitates the use of unwrap()s since the different algorithms have different length requirements that aren't being enforced at compile time.

• Property based testing
• Testing against TVs
• Testing against ref/jasmin moved to #31

Meta issue to track benchmarking.

New Benchmarks

• ed25519 benchmarks
• P Curves (ECDH/ECDSA) benchmarks
• hmac benchmarks
• hkdf benchmarks

Comparisons

• Add https://github.com/oconnor663/blake2_simd
• symcrypt
• between different implementations in libcrux
  • #31

• add categories
• update links

The HPKE API is the (hac)spec API right now, which isn't great to use.
Add a high-level, usable API on top.

The crate::kem module is currently written with only elliptic curves in mind (see for example impl From<Algorithm> for ecdh::Algorithm here).

When Kyber is added, the From implementation above will have to be changed to a TryFrom, and so on.

Follow-up to #10

HACL code that uses allocations isn't working right now for some reason.

Use cc for the libjade build.
Using it for hacl will be tackled when actually using it in #47 .

The signature API isn't great right now. It should be updated to be easier to use and cover all signature algorithms.

          Do we need this error type or shall would it make more sense to pull this up into the main error type of libcrux?

This was necessary in the hazmat case. But I think it might be nicer if we skip it here.

Originally posted by @franziskuskiefer in #63 (comment)

• ensure the build and tests are working
• add the target to CI

We should clean up the fuzzing code and make it more comprehensive. We could fuzz the Kyber code for a couple of minutes on each PR, and run a longer job where we fuzz the code for an hour or so every night.