Retour aux mises à jour
New releaseSep 3, 2026

rscrypto v0.9.0

Cryptographie Rust sans aucune dépendance requise : hachages, sommes de contrôle, MAC, KDF, hachage de mots de passe, AEAD, signatures, RSA, échange de clés, ML-KEM et ML-DSA. Référence Rust portable avec backends SIMD et ASM.

Partager

rscrypto

Crates.io Docs.rs MSRV 1.100.0 License: MIT OR Apache-2.0

rscrypto est une bibliothèque Rust de primitives cryptographiques, de hachages, de hachage de mots de passe et de sommes de contrôle. Un seul modèle de fonctionnalités les contrôle toutes. Le Rust portable est l'implémentation de référence. Les backends SIMD et assembleur l'accélèrent sur les cibles prises en charge. Les builds de production ne dépendent ni de C, ni de FFI, ni d'OpenSSL, ni de bibliothèques système.

rscrypto ne fournit que des primitives. Ce n'est pas une pile TLS, une boîte à outils PKI, un magasin de clés ni une implémentation de protocole.

Installation

rscrypto nécessite Rust 1.100. Tant que Rust 1.100 n'est pas stable, utilisez la bêta 1.100 ou une nightly plus récente. Les builds accélérés POWER, IBM Z et RISC-V nécessitent un compilateur nightly ; les builds portable-only prennent en charge la MSRV déclarée. Voir Toolchain.

Build no_std minimal avec SHA-2 uniquement :

[dependencies]
rscrypto = { version = "0.11", default-features = false, features = ["sha2"] }

Toutes les primitives, avec le hasard du système d'exploitation :

[dependencies]
rscrypto = { version = "0.11", features = ["full", "getrandom"] }

La fonctionnalité par défaut est std. Définissez default-features = false pour la retirer. Activez getrandom uniquement pour les API qui obtiennent des sels, des clés, des nonces ou l'entropie de génération de clés RSA depuis le système d'exploitation. Le guide des fonctionnalités explique comment sélectionner les fonctionnalités. Cargo.toml définit le graphe exact des fonctionnalités.

Démarrage rapide

use rscrypto::Sha256;

let one_shot = Sha256::digest(b"hello world");

let mut hasher = Sha256::new();
hasher.update(b"hello ");
hasher.update(b"world");

assert_eq!(hasher.finalize(), one_shot);

Les types de hachage prennent en charge l'usage en un seul appel et en flux. examples/README.md contient des exemples exécutables pour AEAD, les signatures, RSA, ECDH P-256 et P-384, X25519, ML-KEM, le hachage de mots de passe et l'introspection des backends.

Primitives et fonctionnalités

FamillePrimitivesFonctionnalité
Sommes de contrôleCRC-16, CRC-24, CRC-32, CRC-32C, CRC-64/XZ, CRC-64/NVMechecksums ou une fonctionnalité feuille
Hachages cryptographiquesSHA-2, SHA-3, SHAKE, cSHAKE, BLAKE2, BLAKE3, Ascon-Hash/XOF/CXOFcrypto-hashes ou une fonctionnalité feuille
Hachages rapidesXXH3-64/128, RapidHash V3-64fast-hashes ou une fonctionnalité feuille
MACs et KDFsHMAC-SHA-2/SHA-3, KMAC128/256, Poly1305, HKDF-SHA-2, PBKDF2-HMAC-SHA-2macs, kdfs ou une fonctionnalité feuille
Hachage de mots de passeArgon2d/i/id, scrypt, enregistrements de mots de passe PHC bornéspassword-hashing ou une fonctionnalité feuille
Signatures et RSAECDSA P-256/P-384, Ed25519, ML-DSA-44/65/87, SLH-DSA (les 12 ensembles FIPS 205, pure et HashSLH-DSA), signature, vérification, chiffrement et génération de clés RSAsignatures ou une fonctionnalité feuille
Échange de clés et KEMsECDH P-256, ECDH P-384, X25519, ML-KEM-512/768/1024key-exchange ou une fonctionnalité feuille
AEADsAES-GCM, AES-GCM-SIV, AES-SIV-CMAC, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, Ascon-AEAD128aead ou une fonctionnalité feuille

Les clés de signature et de KEM importent et exportent du DER standard (PKCS #8 et SubjectPublicKeyInfo) pour ECDSA, Ed25519, RSA, ML-DSA, ML-KEM et SLH-DSA.

Le digest d'acceptation WebSocket n'existe que pour la compatibilité de protocole. Il nécessite la fonctionnalité websocket-sha1. Aucune fonctionnalité parapluie, y compris full, ne l'active.

Voir docs.rs pour les types et méthodes exacts. Les notes de compatibilité de l'API expliquent les types de sortie, les graines de collection et les noms de méthodes conservés. Le guide de résilience cryptographique explique les hypothèses de sécurité, les frontières de migration et les preuves à examiner lors du choix d'une cryptographie plus forte.

Plateformes et répartition

L'implémentation Rust portable définit la sortie correcte, octet par octet. Chaque backend accéléré doit produire la même sortie. À la compilation, la cible détermine quels backends sont disponibles. Avec std, rscrypto détecte aussi les fonctionnalités du CPU à l'exécution et sélectionne un backend. Si aucun backend accéléré n'est disponible, l'implémentation portable s'exécute.

Le guide des plateformes liste les cibles prises en charge. Il explique aussi la répartition, la prise en charge de no_std et les limites de portable-only.

Assurance

Une affirmation de sécurité n'existe que tant que ses preuves passent. Des preuves manquantes ou anciennes suppriment l'affirmation ; elles n'affaiblissent jamais un contrôle.

  • Exactitude : vecteurs NIST, RFC, upstream et Wycheproof, implémentations indépendantes, tests de propriétés, tests négatifs et Miri.
  • Fuzzing : les cibles de fuzzing exécutent le code de production sur les primitives, les parseurs, les machines à états et les frontières de traits. Les entrées minimisées sont rejouées comme tests. Une voie séparée les exécute avec des sanitizers.
  • Backends : des tests différentiels comparent chaque backend accéléré au Rust portable. Ils couvrent les longueurs, les alignements, les queues, les transitions d'état, la répartition et le repli sur les cibles natives.
  • Temps constant : ct.toml liste les opérations exactes testées. Les preuves combinent l'inspection des binaires liés optimisés, des preuves BINSEC pour les noyaux à forme fixe et des tests de timing DudeCT pour les opérations de bout en bout.
  • Secrets : les types qui possèdent des secrets masquent leur contenu dans la sortie Debug et effacent leur stockage initialisé lors du drop. Les règles de copie varient selon le type ; par exemple, l'état de BLAKE2 et BLAKE3 à clé prend en charge Clone. L'inventaire de propriété des secrets liste chaque type.
  • Échecs : les échecs de vérification n'indiquent pas pourquoi ils ont échoué. Une ouverture AEAD échouée efface le texte en clair non authentifié.

Une affirmation de temps constant ne s'applique qu'à la cible, aux fonctionnalités, au compilateur, au profil et à l'opération que ses preuves couvrent. Un code source qui semble sans branchement n'est pas une preuve.

Pour plus de détails, voir les preuves de test, le modèle de temps constant, le cycle de vie des secrets et le modèle de menace.

Catégories