Microcontroller optimizations.

[nickray]

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 https://github.com/RustCrypto/elliptic-curves/issues/54 whether to enforce correct but slow constant-time scalar inversion, or open the door to non-constant time implementations which might be abused.

[tarcieri]

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.

[newpavlov]

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.