Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit curve25519-dalek #75

Open
dbrgn opened this issue Oct 20, 2021 · 2 comments
Open

Audit curve25519-dalek #75

dbrgn opened this issue Oct 20, 2021 · 2 comments

Comments

@dbrgn
Copy link

dbrgn commented Oct 20, 2021

The curve25519-dalek crate has almost 5 million downloads (1.3 million of those in the last 90 days). It is a building block for many crypto libraries.

The library only uses unsafe for the two SIMD-backends (avx2 / ifma). From the README:

//! The implementation is memory-safe, and contains no significant
//! `unsafe` code.  The SIMD backend uses `unsafe` internally to call SIMD
//! intrinsics.  These are marked `unsafe` only because invoking them on an
//! inappropriate CPU would cause `SIGILL`, but the entire backend is only
//! compiled with appropriate `target_feature`s, so this cannot occur.

However, it would still be good if someone would audit those usages and maybe upload a cargo-crev review.

@Shnatsel
Copy link
Member

Shnatsel commented Mar 7, 2022

I see two things that could be done here:

  • Use the safe_arch crate to delegate the unsafe code to it (it provides safe wrappers for SIMD intrinsics)
  • Use the (nightly-only) portable SIMD types from the standard library, which get lowered into target-appropriate instructions.

I am not sufficiently familiar with SIMD and safe_arch crate to tell whether migrating to it is a good idea in this case.

@tarcieri
Copy link
Member

tarcieri commented Mar 7, 2022

It already uses packed_simd(_2), which is the predecessor of std::simd, so it would probably make sense to eventually migrate to the implementation that's in nightly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants