RustCrypto: Leighton-Micali签名

此仓库包含Leighton-Micali基于哈希的签名（RFC 8554）的实现。

安全通知

LMS签名是状态的：用户必须注意不要用同一个内部LM-OTS私钥签名多于一条消息。为了避免灾难，状态必须在多次调用签名算法之间维护。

在每次返回签名之前，LMS内部计数器（q）将被递增。

如果LMS私钥被持久化到存储，必须在签名生成后和将其发布到应用程序其他部分之前更新持久化存储。未能遵守此要求会在您的应用程序中造成安全漏洞。

有关无状态的基于哈希的签名算法，请参阅SLH-DSA。

注意：此项目尚未经过外部审计，但整个代码库已由Trail of Bits的密码学家内部审查。

安装

cargo install

用法

我们的实现使用强类型化的私钥和公钥类型。

let mut rng = thread_rng();
let mut seckey = lms::lms::PrivateKey::new::<LmsSha256M32H10<LmsOtsSha256N32W4> > ( & mut rng);
let pubkey = seckey.public();   // of type lms::lms::PublicKey<LmsSha256M32H10>
let sig    = seckey.try_sign_with_rng( & mut rng, "example".as_bytes()).unwrap();
let sig_valid = pubkey.verify("example".as_bytes(), & sig).is_ok();

我们可以使用lms::ots::PrivateKey以相同的方式生成LMOTS签名。

密钥管理

在密钥管理方面，我们对用户的要求不多。任何内部状态更改操作都使用可变引用来更新内部状态。当将私钥持久化到长期存储时，用户必须非常小心，确保“相同的私钥永远不会从磁盘读取两次”。这将创建两个处于相同状态的私钥，因此当它们都用于签名消息时，LMOTS私钥将被重用，这被认为是不好的。

许可证

所有crates都根据以下之一获得许可：

• Apache许可证，版本2.0
• MIT许可证

任选。

贡献

除非您明确声明，否则您提交的任何贡献，根据Apache-2.0许可证定义，应作为上述双重许可，不附加任何额外条款或条件。