curve25519-dalek-source/ed25519-dalek/Cargo.toml

93 lines
3 KiB
TOML
Raw Normal View History

2016-12-01 00:40:48 +00:00
[package]
name = "ed25519-dalek"
2026-06-18 05:42:04 +00:00
version = "3.0.0-rc.1"
edition = "2024"
authors = [
"isis lovecruft <isis@patternsinthevoid.net>",
"Tony Arcieri <bascule@gmail.com>",
2025-07-09 17:04:17 +00:00
"Michael Rosenberg <michael@mrosenberg.pub>",
]
2016-12-01 00:40:48 +00:00
readme = "README.md"
2017-10-05 06:19:55 +00:00
license = "BSD-3-Clause"
2023-09-06 04:49:26 +00:00
repository = "https://github.com/dalek-cryptography/curve25519-dalek/tree/main/ed25519-dalek"
homepage = "https://github.com/dalek-cryptography/curve25519-dalek"
documentation = "https://docs.rs/ed25519-dalek"
keywords = ["cryptography", "ed25519", "curve25519", "signature", "ECC"]
categories = ["cryptography", "no-std"]
description = "Fast and efficient ed25519 EdDSA key generations, signing, and verification in pure Rust."
2025-07-09 17:04:17 +00:00
exclude = [".gitignore", "TESTVECTORS", "VALIDATIONVECTORS", "res/*"]
rust-version = "1.85"
2016-12-01 00:40:48 +00:00
[package.metadata.docs.rs]
rustdoc-args = [
2025-07-09 17:04:17 +00:00
"--html-in-header",
"docs/assets/rustdoc-include-katex-header.html",
"--cfg",
"docsrs",
]
all-features = true
2019-10-25 22:18:42 +00:00
[dependencies]
2026-06-18 05:42:04 +00:00
curve25519-dalek = { version = "5.0.0-rc.1", default-features = false, features = [
2025-07-09 17:04:17 +00:00
"digest",
] }
ed25519-dalek: bump `ed25519` crate dependency to v3.0.0 (#903) * [WIP] ed25519-dalek: bump `ed25519` crate dependency to v3.0.0 This has two test failures: serialisation::serialize_deserialize_signature_json serialisation::serialize_signature_size These are due to a last minute change to use `serdect` for implementing `serde` support: RustCrypto/signatures#1324. The signature size regression from `64` to `72` is a deliberate tradeoff we've accepted in `serdect`. First note that this test is for now the unmaintained `bincode` crate. The core problem is that `serde` does not actually provide fixed-size arrays as a type within its data model (serde-rs/serde#1937) and you're instead left faking it using `SerializeTuple` and serializing it a byte-at-a-time as a tuple. While this gives optimal-sized results on `bincode`, it gives less-than-optimal results on e.g. `rmp-serde` where the bytes each end up tagged with a type prefix. `serde` does provide portable APIs for using optimal format-specific byte encodings, but they carry an additional length prefix, which is unnecessary and suboptimal for something fixed-width like an Ed25519 signature, but alas as noted earlier `serde` does not actually have fixed-width arrays in its data model. The second test failure occurs specifically because `serdect` introspects the format and uses `base16ct` to perform hex serialization for human readable formats. While this is a readability improvement for these formats (and also makes them easier to implement in constant-time, though it's not relevant here), the drawback is it currently requires the `alloc` feature for such formats, which is a regression: Error("serializer is human readable, which requires the `alloc` crate feature", line: 0, column: 0) Note that regardless these are both breaking changes to how `serde` serialization is handled. See also: - RustCrypto/formats#1111 - RustCrypto/formats#1112 - dalek-cryptography/ed25519-dalek#140 * Migrate bincode -> postcard * Bump `serdect` to v0.4.3 Includes `no_alloc` hex serialization support --------- Co-authored-by: Michael Rosenberg <mrosenberg@cloudflare.com>
2026-05-04 02:26:26 +00:00
ed25519 = { version = "3", default-features = false }
signature = { version = "3", optional = true, default-features = false }
sha2 = { version = "0.11", default-features = false }
subtle = { version = "2.3.0", default-features = false }
# optional features
keccak = { version = "0.2", default-features = false, optional = true }
rand_core = { version = "0.10", default-features = false, optional = true }
serde = { version = "1.0", default-features = false, optional = true }
zeroize = { version = "1.5", default-features = false, optional = true }
strobe-rs = { version = "0.13", optional = true }
[dev-dependencies]
2026-06-18 05:42:04 +00:00
curve25519-dalek = { version = "5.0.0-rc.1", default-features = false, features = [
2025-07-09 17:04:17 +00:00
"digest",
"rand_core",
] }
2026-06-18 05:42:04 +00:00
x25519-dalek = { version = "3.0.0-rc.1", default-features = false, features = [
2025-07-09 17:04:17 +00:00
"static_secrets",
] }
blake2 = "0.11.0-rc.6"
chacha20 = { version = "0.10", default-features = false, features = ["rng"] }
sha3 = "0.11"
getrandom = { version = "0.4", features = ["sys_rng"] }
hex = "0.4"
ed25519-dalek: bump `ed25519` crate dependency to v3.0.0 (#903) * [WIP] ed25519-dalek: bump `ed25519` crate dependency to v3.0.0 This has two test failures: serialisation::serialize_deserialize_signature_json serialisation::serialize_signature_size These are due to a last minute change to use `serdect` for implementing `serde` support: RustCrypto/signatures#1324. The signature size regression from `64` to `72` is a deliberate tradeoff we've accepted in `serdect`. First note that this test is for now the unmaintained `bincode` crate. The core problem is that `serde` does not actually provide fixed-size arrays as a type within its data model (serde-rs/serde#1937) and you're instead left faking it using `SerializeTuple` and serializing it a byte-at-a-time as a tuple. While this gives optimal-sized results on `bincode`, it gives less-than-optimal results on e.g. `rmp-serde` where the bytes each end up tagged with a type prefix. `serde` does provide portable APIs for using optimal format-specific byte encodings, but they carry an additional length prefix, which is unnecessary and suboptimal for something fixed-width like an Ed25519 signature, but alas as noted earlier `serde` does not actually have fixed-width arrays in its data model. The second test failure occurs specifically because `serdect` introspects the format and uses `base16ct` to perform hex serialization for human readable formats. While this is a readability improvement for these formats (and also makes them easier to implement in constant-time, though it's not relevant here), the drawback is it currently requires the `alloc` feature for such formats, which is a regression: Error("serializer is human readable, which requires the `alloc` crate feature", line: 0, column: 0) Note that regardless these are both breaking changes to how `serde` serialization is handled. See also: - RustCrypto/formats#1111 - RustCrypto/formats#1112 - dalek-cryptography/ed25519-dalek#140 * Migrate bincode -> postcard * Bump `serdect` to v0.4.3 Includes `no_alloc` hex serialization support --------- Co-authored-by: Michael Rosenberg <mrosenberg@cloudflare.com>
2026-05-04 02:26:26 +00:00
postcard = { version = "1", features = ["alloc"] }
serde_json = "1.0"
criterion = { version = "0.5", features = ["html_reports"] }
hex-literal = "1"
serde = { version = "1.0", features = ["derive"] }
2025-09-04 15:32:20 +00:00
toml = { version = "0.9" }
[[bench]]
name = "ed25519_benchmarks"
harness = false
required-features = ["rand_core"]
[features]
default = ["fast", "zeroize"]
2025-07-09 17:04:17 +00:00
alloc = [
"curve25519-dalek/alloc",
"ed25519/alloc",
"signature/alloc",
"serde?/alloc",
"zeroize?/alloc",
]
batch = ["alloc", "dep:keccak", "rand_core", "strobe-rs"]
fast = ["curve25519-dalek/precomputed-tables"]
digest = ["signature/digest"]
# Exposes the hazmat module
hazmat = []
# Turns off stricter checking for scalar malleability in signatures
legacy_compatibility = ["curve25519-dalek/legacy_compatibility"]
pkcs8 = ["ed25519/pkcs8"]
pem = ["alloc", "ed25519/pem", "pkcs8"]
rand_core = ["dep:rand_core"]
serde = ["dep:serde", "ed25519/serde"]
zeroize = ["dep:zeroize", "curve25519-dalek/zeroize"]