saymrwulf/curve25519-dalek-source
1
0
Fork 0
mirror of https://github.com/saymrwulf/curve25519-dalek-source.git synced 2026-09-04 20:24:10 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
curve25519-dalek-source/Cargo.toml

81 lines
2.7 KiB
TOML
Raw Normal View History

Initial commit.
2016-12-08 05:12:00 +00:00
[package]
name = "curve25519-dalek"
Change version to 0.18.0 (since feature flags changed)
2018-06-22 19:24:20 +00:00
version = "0.18.0"
Initial commit.
2016-12-08 05:12:00 +00:00
authors = ["Isis Lovecruft <isis@patternsinthevoid.net>",
"Henry de Valence <hdevalence@hdevalence.ca>"]
readme = "README.md"
Fix licence
2017-08-01 02:05:31 +00:00
license = "BSD-3-Clause"
Update links to point to new official repos.
2018-01-20 00:54:46 +00:00
repository = "https://github.com/dalek-cryptography/curve25519-dalek"
homepage = "https://dalek.rs/curve25519-dalek"
Initial commit.
2016-12-08 05:12:00 +00:00
documentation = "https://docs.rs/curve25519-dalek"
Add "cryptography" and "no-std" categories
2017-02-14 16:34:24 +00:00
categories = ["cryptography", "no-std"]
Bump version to 0.15
2018-02-06 18:52:10 +00:00
keywords = ["cryptography", "ristretto", "curve25519", "ECC"]
description = "A pure-Rust implementation of group operations on Ristretto and Curve25519"
Initial commit.
2016-12-08 05:12:00 +00:00
exclude = [
Exclude all .gitignore files from all builds.
2017-12-01 01:28:33 +00:00
"**/.gitignore",
Include rustdoc-include-katex-header.html in package.
2017-11-16 01:13:30 +00:00
".gitignore",
Exclude .travis.yml from packages.
2017-11-16 01:13:57 +00:00
".travis.yml",
Include rustdoc-include-katex-header.html in package.
2017-11-16 01:13:30 +00:00
]
First attempt at generating basepoint tables at compile time
2017-10-31 21:07:27 +00:00
build = "build.rs"
Initial commit.
2016-12-08 05:12:00 +00:00
I think this will add KaTeX into docs.rs ???
2017-11-15 18:09:52 +00:00
[package.metadata.docs.rs]
No idea how this XSS will work when the hash after "github.com-" changes.
2017-11-16 01:32:23 +00:00
rustdoc-args = ["--html-in-header", ".cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-0.13.2/rustdoc-include-katex-header.html"]
Try to tell docs.rs to build using the "nightly" feature We need this to put the README.md into the docs, or else the crate description is bare.
2018-02-06 19:18:02 +00:00
features = ["nightly"]
I think this will add KaTeX into docs.rs ???
2017-11-15 18:09:52 +00:00
Add a Travis badge to the Cargo.toml package.
2017-03-14 03:38:13 +00:00
[badges]
Update more links to point to the official CI and repos.
2018-01-20 00:55:50 +00:00
travis-ci = { repository = "dalek-cryptography/curve25519-dalek", branch = "master"}
Add a Travis badge to the Cargo.toml package.
2017-03-14 03:38:13 +00:00
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
[dev-dependencies]
sha2 = "0.7"
serde_cbor = "0.6"
Use `criterion.rs` instead of libtest for benchmarks. Since Criterion can only benchmark public API, these changes just drop all internal benchmarks (e.g., benchmarks for field operations). But those are usually microbenchmarks whose meaning is kind of questionable anyways, so I don't think this is a big loss. The `bench` feature disappears, since Criterion works on stable Rust.
2018-03-26 00:10:30 +00:00
criterion = "0.2"
[[bench]]
name = "dalek_benchmarks"
harness = false
first avx2 code
2017-10-23 21:03:23 +00:00
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
# Note: we generate precomputed tables by building the crate twice: once as
# part of build.rs, and then once "for real".
#
# This means that the [dependencies] and [build-dependencies] sections must
# match exactly, since the build.rs uses the crate itself as a library.
Initial work on Serde support
2017-05-14 05:40:51 +00:00
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
[dependencies]
Update rand dependency to 0.5.
2018-07-03 21:09:02 +00:00
rand = { version = "0.5", default-features = false }
Replace Scalar::from_u64 with From impls Unfortunately, Rust selects `i32` as the type for an integer literal when the literal has no other type constraints. This means that someone cannot write `Scalar::from(1)`, as Rust will choose `i32` as the type for `1`, and we don't `impl From<i32> for Scalar`. We could implement `From` conversions for signed integers, but since `Scalar` operations should be constant-time by default, this would require us to extract the sign bit of the integer and use it to conditionally select between the positive and negative of Scalar constructed from the value bits. This is more expensive than the unsigned operation, and I don't think it's what anyone really wants. Making API consumers specify that their literals are unsigned is slightly annoying, but better than the above alternative. It would also be nice to change `Scalar::from_hash` to be `impl<D: Digest<OutputSize = U64>> From<D> for Scalar`, but this isn't currently allowed by Rust (since that `impl` "could" conflict with the `impl From<u8>` if someone decided that `u8` should `impl Digest`).
2018-07-17 17:53:02 +00:00
byteorder = { version = "1", default-features = false, features = ["i128"] }
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
digest = "0.7"
generic-array = "0.9"
clear_on_drop = "=0.2.3"
Bump subtle dependency to 0.7.0.
2018-07-04 19:56:16 +00:00
subtle = { version = "0.7", features = ["generic-impls"], default-features = false }
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
serde = { version = "1.0", optional = true }
Make serde an optional feature
2017-05-15 01:06:59 +00:00
First attempt at generating basepoint tables at compile time
2017-10-31 21:07:27 +00:00
[build-dependencies]
Update rand dependency to 0.5.
2018-07-03 21:09:02 +00:00
rand = { version = "0.5", default-features = false }
Replace Scalar::from_u64 with From impls Unfortunately, Rust selects `i32` as the type for an integer literal when the literal has no other type constraints. This means that someone cannot write `Scalar::from(1)`, as Rust will choose `i32` as the type for `1`, and we don't `impl From<i32> for Scalar`. We could implement `From` conversions for signed integers, but since `Scalar` operations should be constant-time by default, this would require us to extract the sign bit of the integer and use it to conditionally select between the positive and negative of Scalar constructed from the value bits. This is more expensive than the unsigned operation, and I don't think it's what anyone really wants. Making API consumers specify that their literals are unsigned is slightly annoying, but better than the above alternative. It would also be nice to change `Scalar::from_hash` to be `impl<D: Digest<OutputSize = U64>> From<D> for Scalar`, but this isn't currently allowed by Rust (since that `impl` "could" conflict with the `impl From<u8>` if someone decided that `u8` should `impl Digest`).
2018-07-17 17:53:02 +00:00
byteorder = { version = "1", default-features = false, features = ["i128"] }
Update digest => 0.7, generic_array => 0.9 These are the latest releases of these crates.
2017-12-16 21:13:58 +00:00
digest = "0.7"
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
generic-array = "0.9"
Clear scalar digits from memory in multiscalar_mult
2017-11-28 22:40:50 +00:00
clear_on_drop = "=0.2.3"
Bump subtle dependency to 0.7.0.
2018-07-04 19:56:16 +00:00
subtle = { version = "0.7", features = ["generic-impls"], default-features = false }
Consolidate Cargo.toml and document the weird build hack
2018-01-27 00:29:23 +00:00
serde = { version = "1.0", optional = true }
First attempt at generating basepoint tables at compile time
2017-10-31 21:07:27 +00:00
Add #![no_std] (fixes #16) Use ::core in lieu of ::std, allowing this crate to be usable in #![no_std] environments. Gates features that presently depend on ::std (presently just rand) behind a "std" cargo feature, which is enabled by default.
2017-01-14 01:43:08 +00:00
[features]
Rework backend selection code. Each backend can now be selected by an individual feature: - `u32_backend` for `backend::u32`; - `u64_backend` for `backend::u64`; - `avx2_backend` for `backend::avx2`; The `u64_backend` is selected by default, since most people use X64 and we have no way to select based on target (see discussion in #126). However, these changes mean that it is possible to select the backend explicitly, and if we had the ability to select target-default features, we could do so easily.
2018-05-15 00:35:34 +00:00
nightly = ["subtle/nightly", "clear_on_drop/nightly"]
default = ["std", "u64_backend"]
Unify `alloc` and `std` cargo features This change provides a common convention for using allocator-dependent features with: #![cfg(feature = "alloc")] When available, `Vec` is imported consistently as `prelude::Vec`, which means modules that need access to `Vec` can simply do: use prelude::*; and if an allocator is available, `Vec` will be in the crate prelude. This allows all `alloc` vs `std` gating to be handled in `lib.rs`, `build.rs`, and `prelude.rs` so the rest of the codebase doesn't have to do any gating whatsoever.
2018-07-20 21:43:31 +00:00
std = ["alloc", "subtle/std", "rand/std"]
Switch from libcollections to liballoc (gated on an "alloc" feature) libcollections was recently merged into liballoc: https://github.com/rust-lang/rust/pull/42648 I went ahead and also added an "alloc" feature which no_std users can use to opt into liballoc features (i.e. any code using Vec). This should have no effect on anything but no_std usage. It does make it possible for people without allocators to use curve25519-dalek if they want though. Might be nice for "bare metal" development. All that said, from what I can gather liballoc, while not "stable", should likely stick around for the forseeable future. Some backstory on the liballoc/libcollections merge here: https://github.com/rust-lang/rust/pull/42565
2017-06-19 23:59:45 +00:00
alloc = []
Rework backend selection code. Each backend can now be selected by an individual feature: - `u32_backend` for `backend::u32`; - `u64_backend` for `backend::u64`; - `avx2_backend` for `backend::avx2`; The `u64_backend` is selected by default, since most people use X64 and we have no way to select based on target (see discussion in #126). However, these changes mean that it is possible to select the backend explicitly, and if we had the ability to select target-default features, we could do so easily.
2018-05-15 00:35:34 +00:00
yolocrypto = []
# The u32 backend uses u32s with u64 products.
u32_backend = []
# The u64 backend uses u64s with u128 products.
u64_backend = []
# The AVX2 backend uses u32x8s with u64x4 products.
# It uses the u64 code for serial operations.
avx2_backend = ["nightly", "u64_backend"]
Rename 'precomputed_tables' to the more accurate 'stage2_build'
2018-05-14 22:41:45 +00:00
# Signals that we're in the main build stage. This is off by default,
# to signal stage 1 of the build, where build.rs loads the library
# into the build script. Then, the build.rs emits the stage2_build
# feature before the main-stage compilation.
stage2_build = []
Reference in a new issue Copy permalink