ed25519-dalek

在Rust中实现ed25519密钥生成、签名和验证的快速且高效的方法。

文档

文档可在此处找到。

安装

要安装，请将以下内容添加到您项目的Cargo.toml

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

基准测试

在运行于3.30 GHz且无TurboBoost功能的Intel Skylake i9-7900X处理器上，此代码实现了以下性能基准

∃!isisⒶmistakenot:(master *=)~/code/rust/ed25519-dalek ∴ cargo bench
   Compiling ed25519-dalek v0.7.0 (file:///home/isis/code/rust/ed25519-dalek)
    Finished release [optimized] target(s) in 3.11s
      Running target/release/deps/ed25519_benchmarks-721332beed423bce

Ed25519 signing                     time:   [15.617 us 15.630 us 15.647 us]
Ed25519 signature verification      time:   [45.930 us 45.968 us 46.011 us]
Ed25519 keypair generation          time:   [15.440 us 15.465 us 15.492 us]

通过启用avx2后端（适用于兼容的微架构的机器），签名验证的性能得到了显著提升

∃!isisⒶmistakenot:(master *=)~/code/rust/ed25519-dalek ∴ export RUSTFLAGS=-Ctarget_cpu=native
∃!isisⒶmistakenot:(master *=)~/code/rust/ed25519-dalek ∴ cargo bench --features=avx2_backend
   Compiling ed25519-dalek v0.7.0 (file:///home/isis/code/rust/ed25519-dalek)
    Finished release [optimized] target(s) in 4.28s
      Running target/release/deps/ed25519_benchmarks-e4866664de39c84d
Ed25519 signing                     time:   [15.923 us 15.945 us 15.967 us]
Ed25519 signature verification      time:   [33.382 us 33.411 us 33.445 us]
Ed25519 keypair generation          time:   [15.246 us 15.260 us 15.275 us]

相比之下，Golang中相应的包表现如下

∃!isisⒶmistakenot:(master *=)~/code/go/src/github.com/agl/ed25519 ∴ go test -bench .
BenchmarkKeyGeneration     30000             47007 ns/op
BenchmarkSigning           30000             48820 ns/op
BenchmarkVerification      10000            119701 ns/op
ok      github.com/agl/ed25519  5.775s

将密钥生成和签名速度提高了大约2倍，验证速度提高了2.5-3倍（取决于avx2的可用性）。当然，这只是我的机器，这些结果——远非严谨——应该带着几粒盐来对待。

将其转换为大致的周期数：我们通过3.3倍的因子将纳秒转换为3300 MHz CPU的每秒周期数，验证为110256周期，签名为52618周期，这可以与手动优化的汇编实现相媲美。

此外，如果您正在使用来自randcrate的CSPRNG，nightly功能将启用那里的u128/i128功能，从而可能提高性能。

如果您的协议或应用程序能够批量进行签名验证，那么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-Curve 数字签名算法（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 支持，请使用 ed25519-dalek 的 serde 功能进行构建。

(微)架构特定后端

默认情况下，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 功能启用与上面相同的批量签名验证概念，但使用纯确定性随机性。