如果你的协议或应用程序能够批量签名进行验证，那么verify_batch()函数的性能得到了显著提升。在上述的Intel Skylake i9-7900X处理器上，验证96个签名的批处理耗时为1.7673毫秒。这相当于每个签名验证18.4094微秒，大约是60750个周期，比原始论文中给出的批处理验证速度快了一倍多（这很可能不是一个公平的比较，因为那是Nehalem机器）。测试名称中/后面的数字指的是批处理的大小

∃!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，“Edwards曲线数字签名算法（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（密码学安全的随机数生成器）。特别是在签名验证的情况下，安全性证明 依赖于 遮蔽因子/非ces 的唯一性，因此这些随机样本对于攻击者来说是不可预测的。正因为如此，密码学家当前普遍认为，选择 合成随机数 更安全。

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

在默认模式下，我们像在完全确定性模式下那样做，但是根据系统/芯片提供的随机数将底层 keccak-f1600 函数（用于提供的基于转写的 PRNG）向前推进。这提供了 合成随机数，即基于确定性和非确定性数据的随机数。这样做的原因是为了防止不良的种子系统 RNGs 破坏签名验证方案的安全性。

功能

#![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 功能启用。