2个版本
使用旧的Rust 2015
1.0.0-pre.3 | 2020年1月24日 |
---|---|
1.0.0-pre.2 | 2019年8月25日 |
1.0.0-pre.1 |
|
#28 in #ed25519-key
97KB
969 行
ed25519-dalek

ed25519密钥生成、签名和验证的Rust实现,速度快、效率高。
文档
文档可在此处找到。
安装
要安装,请在项目的Cargo.toml
中添加以下内容
[dependencies.ed25519-dalek]
version = "1"
基准测试
在3.30 GHz的Intel Skylake i9-7900X上运行,不启用TurboBoost,此代码达到了以下性能基准
∃!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]
相比之下,Go语言中的等效包表现如下
∃!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周期,这与手动优化的汇编实现具有竞争力。
此外,如果您使用来自rand
crate的CSPRNG,nightly
功能将启用那里的u128
/i128
功能,从而可能导致性能提升。
如果您的协议或应用能够批量进行签名验证,那么verify_batch()
函数的性能得到了极大提升。在上述英特尔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,“爱德华曲线数字签名算法(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()
函数
签名的标量组件并不是签名可变形的唯一来源。用于签名验证的公钥和签名中的群元素组件也都是可变形的,因为它们可能包含由于曲线25519群不是素数阶但有一个小的系数为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
功能启用。
依赖项
~1.9–2.7MB
~57K SLoC