∃!isisⒶmistakenot:(master *=)~/code/rust/ed25519-dalek ∴ export RUSTFLAGS=-Ctarget_cpu=native
∃!isisⒶmistakenot:(master *=)~/code/rust/ed25519-dalek ∴ cargo bench --features=avx2_backend batch
   Compiling ed25519-dalek v0.8.0 (file:///home/isis/code/rust/ed25519-dalek)
    Finished release [optimized] target(s) in 34.16s
      Running target/release/deps/ed25519_benchmarks-cf0daf7d68fc71b6
Ed25519 batch signature verification/4   time:   [105.20 us 106.04 us 106.99 us]
Ed25519 batch signature verification/8   time:   [178.66 us 179.01 us 179.39 us]
Ed25519 batch signature verification/16  time:   [325.65 us 326.67 us 327.90 us]
Ed25519 batch signature verification/32  time:   [617.96 us 620.74 us 624.12 us]
Ed25519 batch signature verification/64  time:   [1.1862 ms 1.1900 ms 1.1943 ms]
Ed25519 batch signature verification/96  time:   [1.7611 ms 1.7673 ms 1.7742 ms]
Ed25519 batch signature verification/128 time:   [2.3320 ms 2.3376 ms 2.3446 ms]
Ed25519 batch signature verification/256 time:   [5.0124 ms 5.0290 ms 5.0491 ms]

正如您所看到的，每台机器都有一个最佳的批处理大小，因此您可能希望在自己的目标CPU上测试基准，以找到最佳的大小。对于这台机器，每批大约100个签名是最佳选择

此外，多亏了Rust，这个实现既具有类型安全性，也具有内存安全性。它还易于被更多的人阅读，比那些能够阅读qhasm的人要多得多，这使得它更容易被审计。我们相信，最终，这些特性——结合速度——比仅仅周期数更有价值。

关于签名可塑性的一点说明

本库生成的签名是可塑的，正如在原始论文中所讨论的

虽然我们的Signature结构体中的标量组件严格来说不是可塑的，因为我们在从字节反序列化Signature时放置了约简检查，但对于这个crate中所有类型的签名，由于群元素组件，仍然存在潜在的可塑性问题。

我们可以通过乘以曲线系数来消除后者的可塑性属性，但这会使我们的实现不符合现有所有其他实现的行为。截至本文撰写时，RFC 8032，“埃德沃斯曲线数字签名算法（EdDSA）”，建议进行更强的检查。虽然我们同意应该进行更强的检查，但我们认为在十年之后改变“ed25519验证”的定义是不恰当的，这将与所有其他实现不兼容。

但是，如果您需要这个功能，请参阅verify_strict()函数的文档，它对群元素进行了完全的检查。这个功能默认可用。

如果您出于某种原因——尽管我们强烈建议您不要——需要符合原始的ed25519签名规范，如上文中论文摘录所示，您可以通过--features='legacy_compatibility'禁用标量可塑性检查。我们强烈建议不要这样做。

legacy_compatibility特性

默认情况下，这个库在签名反序列化时对签名的标量组件的可塑性执行更严格的检查。这种更严格的检查，即s < \ell，其中\ell是基点的阶，由RFC8032所规定。然而，这个RFC是在原始论文十年后标准化的，正如上面所述，通常错误地声称可塑性无关紧要。

因此，大多数ed25519实现只执行有限的、更复杂的检查，即标量的最高三位未被设置。如果您需要与旧实现兼容，包括

• ed25519-donna
• Golang的/x/crypto ed25519
• libsodium（仅当使用-DED25519_COMPAT构建时）
• NaCl的"ref"实现
• 可能还有其他一些

然后启用 ed25519-dalek 的 legacy_compatibility 功能。请注意并警告，这样做允许签名可变形，意味着对于同一消息，可能存在两个不同且“有效”的签名，这对于包括但不限于身份验证协议和加密货币交易在内的许多环境来说显然非常危险。

verify_strict() 函数

签名标量组件不是签名可变形的唯一来源。用于签名验证的公钥和签名组元素组件也是可变形的，因为它们可能包含一个小的扭结组件，这是由于 curve25519 群不是素数阶，但有一个小的系数为 8 的原因。

如果您还希望消除这种签名可变形的来源，请查阅 verify_strict() 函数的文档。

关于随机数生成的一个注释

原始论文的规范和 RFC8032 的标准化并没有精确地指定如何生成随机数，除了使用 CSPRNG（密码学安全的随机数生成器）。特别是在签名验证的情况下，安全证明 依赖于 隐藏因子/随机数的唯一性，对于这些随机数的样本来说，它们对于对手是不可预测的是至关重要的。正因为如此，当前在密码学家中普遍认为，选择 合成随机数 更为安全。

为了解释合成随机数，我们首先应该解释 ed25519-dalek 是如何处理 确定性随机数 生成。由于这种模式可能使用户面临故障攻击的风险，其中对手控制所有批量验证的输入（即公钥、签名和消息），可以以特殊的方式构造它们以引起故障（例如，在 RAM 中错误地翻转位，过热处理器等），因此默认情况下禁用此模式。在确定性模式下，我们通过创建基于公共输入的 Fiat-Shamir 转换的 PRNG 来播种 PRNG，以生成我们的隐藏因子/随机数。这种模式对于需要强大审计保证的协议以及那些无法访问安全系统/芯片提供的随机数的协议可能很有用。可以通过 --features='batch_deterministic' 启用此功能。请注意，我们 不支持 确定性签名，因为其中存在许多陷阱，包括意外重复的随机数会泄露密钥。

在默认模式下，我们像上面完全确定性模式那样做，但基于一些系统/芯片提供的随机数，我们还额外推进了底层 keccak-f1600 函数（用于基于提供的基于转写的 PRNG）。这提供了 合成随机数，即基于确定性和非确定性数据的随机数。这样做的原因是防止糟糕的系统 RNG 从中破坏签名验证方案的安全性。

功能

#![no_std]

这个库旨在符合 #![no_std]。如果需要批量验证（--features='batch'），请启用 std 或 alloc 功能之一。

夜间编译器

要使您的应用程序以默认启用夜间功能的 ed25519-dalek 进行构建，请执行以下操作

[dependencies.ed25519-dalek]
version = "1"
features = ["nightly"]

要使您的应用程序在有人使用 cargo build --features="nightly" 构建时启用夜间功能，请将以下内容添加到 Cargo.toml

[features]
nightly = ["ed25519-dalek/nightly"]

Serde

要启用 serde 支持，请使用 serde 功能构建 ed25519-dalek。

(微)架构特定后端

默认情况下，ed25519-dalek 构建针对 curve25519-dalek 的 u64_backend 功能，该功能使用 Rust 的 i128 功能来实现比 u32_backend 功能大约快一倍的速度。然而，当针对 32 位系统时，您可能希望使用 cargo build --no-default-features --features="u32_backend" 进行编译。如果您正在为具有 avx2 指令的机器构建，还有实验性的 simd_backend，目前包括 avx2 或 avx512 后端。要使用它们，请使用以下命令编译：RUSTFLAGS="-C target_cpu=native" cargo build --no-default-features --features="simd_backend"

批量签名验证

通过 batch 功能，可以使用标准批签名验证变体（即，许多使用可能许多不同公钥在可能许多不同消息上生成的签名）。如上所述，它使用合成随机数。

确定性批量签名验证

可以通过 batch_deterministic 功能启用与上述相同的批量签名验证概念，但使用纯粹确定性随机数。