Fully parametrize precomputed basepoint tables about curve25519-dalek HOT 8 CLOSED

I know features are passed to build.rs as environment variables, so maybe dalek could recursively build itself with the table off to generate the table. It might be less fragile if it wrapped through another (sub)crate.

It's probably easier to ship 30k and say 3k tables, a (sub)crate to generate tables for anyone who wants, and a feature to select among the two provided.

from curve25519-dalek.

@hdevalence was talking about hacking something up to this effect before v1.0.0… feel free to triage in if you're still planning to do that, @hdevalence

from curve25519-dalek.

Are you going to switch to a.. I guess it would be a 'finer' comb, e.g. what the goldilocks codebase uses, to reduce the table size?

from curve25519-dalek.

Yeah, Goldilocks is an example here. The idea would be to write a generic comb that would be specialised at compile-time with particular parameters and tables, so that the tables would be more flexible. One reason is that we were talking to someone who wanted to run -dalek on some small ARM chip where code size is an issue; another is that it might be nice to have fast constant-time fixed-base multiscalar multiplication, where it could be good to have smaller tables so that all the tables can fit inside the L1$.

I'm not sure if this is important enough to do before 1.0.

from curve25519-dalek.

If the table size cannot be fixed, then a customtable feature might suffice because then one could add dalek as a git submodule to the ARM crate, add a build script to the ARM crate that generates the table inside the dalek submodule, and uses [patch]/[replace] to point to the git submodule and force the customtable feature on all dependencies.

In this way, your build script could depend on normal dalek since it'd run in a different crate, even if the source for that part of the build script lived inside dalek as a git submodule, but dalek would not do anything strange itself.

from curve25519-dalek.

Some prototype work on this is in the following feature branch: https://github.com/chain/curve25519-dalek/compare/feature/prune-constants...chain:feature/multistage-build

It's a bit hacky, but it works in the following way. The build.rs file uses #[path=...] overrides to include the dalek source into the build.rs crate (thanks to @withoutboats for pointing out this hack). The basepoint tables are cfg-gated on a precomputed_tables feature.

Because it's not possible to pass features to the build.rs crate, but it is possible for build.rs to control features in the main crate, the precomputed_tables feature is disabled by default in Cargo.toml, then re-enabled by build.rs.

In the main compilation stage, the precomputed_tables feature has been re-enabled by build.rs, and the constants.rs source pulls in the generated tables, which are then compiled as normal.

from curve25519-dalek.

(This doesn't touch the issue of variable-size tables at all, but that's a lot easier to do once there's a multi-stage build process).

from curve25519-dalek.

For now it's possible to build dalek without the precomputed basepoint tables. Doing precomputation for multiscalar multiplication would be more general, so I'm going to close this ticket in favor of #125.

from curve25519-dalek.