Microcontroller optimizations. about elliptic-curves HOT 2 OPEN

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.

from elliptic-curves.

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:

https://github.com/RustCrypto/hashes/blob/master/sha2/Cargo.toml#L37

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.

from elliptic-curves.