You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a rather fast implementation of the base field for Cortex-M4/M33 microcontrollers, wrapping stealing the assembly routines in https://github.com/Emill/P256-cortex-ecdh/blob/master/P256-cortex-m4-ecdh-speedopt-gcc.s. Would there be interest to include platform-specific arithmetic implementations in this crate, or should I focus on a "lean and mean" MCU fork?
Some complications are:
use [u32; 8] for base field
assemble routines and commit "binary" to repository (avoids need for assembler in dependent crates)
pick implementation in build.rs, possibly overridable
unit tests require a qemu-tests sub-library
the use of proptest in dev-dependencies breaks the build for no_std due Cargo feature additivity (byteorder with default features, as so often), not sure how to fix this :/
dev dependency hex is std
I'm experimenting with inline assembly as well, which might be pulled in if compiled on nightly
This relates to other decisions as well, such as in #54 whether to enforce correct but slow constant-time scalar inversion, or open the door to non-constant time implementations which might be abused.
The text was updated successfully, but these errors were encountered:
Would there be interest to include platform-specific arithmetic implementations in this crate, or should I focus on a "lean and mean" MCU fork?
Thus far we've generally focused on pure Rust implementations (cc @newpavlov) however some precedent for ASM can be found in https://github.com/RustCrypto/asm-hashes, which we then conditionally pull into the otherwise pure Rust hash implementation gated under an asm feature:
To get the ball rolling, I'd suggest adding the ASM directly to the p256 crate in a PR, and then we can discuss how to split it up.
I'm curious how @newpavlov feels about including some inline assembly directly into the same crate if it's gated under an asm feature (in addition to target-specific gating), now that it seems inline ASM is headed towards stabilization. IMO that would be fine, especially if it requires explicit opt-in via an asm feature.
If it will be implemented using the new asm! macro, then I also think it should be fine to keep it as part of the p256 crate, also it would help to test the new macro. But requiring nightly compiler is pretty strong requirement, especially nowadays, so I guess we could start with linking the s file using cc. Personally I would prefer the asm! option, but since I don't plan to use it in the near future, I will leave decision to you.
P.S.: I also would like to keep licensing simple, so it would be nice if the assembly code will be re-licensed under MIT/Apache as part of the PR.
I have a rather fast implementation of the base field for Cortex-M4/M33 microcontrollers,
wrappingstealing the assembly routines in https://github.com/Emill/P256-cortex-ecdh/blob/master/P256-cortex-m4-ecdh-speedopt-gcc.s. Would there be interest to include platform-specific arithmetic implementations in this crate, or should I focus on a "lean and mean" MCU fork?Some complications are:
[u32; 8]
for base fieldbuild.rs
, possibly overridableqemu-tests
sub-libraryproptest
indev-dependencies
breaks the build forno_std
due Cargo feature additivity (byteorder
with default features, as so often), not sure how to fix this :/hex
isstd
This relates to other decisions as well, such as in #54 whether to enforce correct but slow constant-time scalar inversion, or open the door to non-constant time implementations which might be abused.
The text was updated successfully, but these errors were encountered: