This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate sequoia-openpgp

Dependencies

(53 total, 34 outdated, 2 insecure)

CrateRequiredLatestStatus
 aes^0.80.9.3out of date
 aes-gcm^0.100.11.1out of date
 anyhow^1.0.181.0.104up to date
 base64>=0.21, <0.230.23.1out of date
 block-padding^0.30.4.2out of date
 blowfish^0.90.10.0out of date
 botan^0.10.60.14.0out of date
 buffered-reader^1.3.01.4.1up to date
 bzip2^0.40.6.1out of date
 camellia^0.10.2.1out of date
 cast5^0.110.12.0out of date
 cfb-mode^0.80.9.1out of date
 chrono^0.4.100.4.45up to date
 cipher^0.40.5.2out of date
 des^0.80.9.0out of date
 digest^0.100.11.3out of date
 dsa^0.60.7.0out of date
 dyn-clone^11.0.20up to date
 eax^0.50.6.1out of date
 ecb^0.10.2.1out of date
 ecdsa^0.160.17.0out of date
 ed25519^23.0.0out of date
 ed25519-dalek^23.0.0out of date
 flate2^1.0.11.1.10up to date
 getrandom^0.20.4.3out of date
 idea^0.50.6.0out of date
 idna ⚠️^0.51.1.0insecure
 lalrpop-util^0.200.23.1out of date
 lazy_static^1.4.01.5.0up to date
 libc^0.2.660.2.189up to date
 md-5^0.100.11.0out of date
 memsec>=0.5, <0.70.7.0out of date
 nettle^7.37.5.0up to date
 num-bigint-dig^0.80.9.1out of date
 once_cell^11.21.4up to date
 openssl^0.10.550.10.81up to date
 openssl-sys^0.9.900.9.117up to date
 p256^0.130.14.0out of date
 rand^0.80.10.3out of date
 rand_core^0.60.10.1out of date
 regex^11.13.1up to date
 regex-syntax^0.80.8.11up to date
 ripemd^0.10.2.0out of date
 rsa ⚠️^0.9.00.9.10insecure
 sha1collisiondetection^0.3.10.3.4up to date
 sha2^0.100.11.0out of date
 thiserror^1.0.22.0.21out of date
 twofish^0.70.8.0out of date
 typenum^1.12.01.20.1up to date
 win-crypto-ng^0.5.10.5.1up to date
 winapi^0.3.80.3.9up to date
 x25519-dalek^23.0.0out of date
 xxhash-rust^0.80.8.18up to date

Dev dependencies

(4 total, 2 outdated)

CrateRequiredLatestStatus
 criterion^0.50.8.2out of date
 quickcheck^11.1.0up to date
 rand^0.80.10.3out of date
 rpassword^7.07.5.4up to date

Security Vulnerabilities

rsa: Marvin Attack: potential key recovery through timing sidechannels

RUSTSEC-2023-0071

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available. The crypto-bigint migration (RustCrypto/RSA#394) did not close this. Tracking is RustCrypto/RSA#626 (padding still not constant-time). Implicit rejection work is in RustCrypto/RSA#680; default-path blinding is in RustCrypto/RSA#702.

Still affected as of 2026-09-12: rsa 0.9.10 (latest stable) and rsa 0.10.0-rc.18 (latest). patched = [] is intentional.

Workarounds

Avoid using the rsa crate in settings where attackers can observe timing, for example over the network. Local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

idna: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded

RUSTSEC-2024-0421

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about alternative Unicode back ends for idna.

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.

Additional information

This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.

Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.