
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.
rscrypto
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
| Famille | Primitives | Fonctionnalité |
|---|---|---|
| Sommes de contrôle | CRC-16, CRC-24, CRC-32, CRC-32C, CRC-64/XZ, CRC-64/NVMe | checksums ou une fonctionnalité feuille |
| Hachages cryptographiques | SHA-2, SHA-3, SHAKE, cSHAKE, BLAKE2, BLAKE3, Ascon-Hash/XOF/CXOF | crypto-hashes ou une fonctionnalité feuille |
| Hachages rapides | XXH3-64/128, RapidHash V3-64 | fast-hashes ou une fonctionnalité feuille |
| MACs et KDFs | HMAC-SHA-2/SHA-3, KMAC128/256, Poly1305, HKDF-SHA-2, PBKDF2-HMAC-SHA-2 | macs, kdfs ou une fonctionnalité feuille |
| Hachage de mots de passe | Argon2d/i/id, scrypt, enregistrements de mots de passe PHC bornés | password-hashing ou une fonctionnalité feuille |
| Signatures et RSA | ECDSA 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 RSA | signatures ou une fonctionnalité feuille |
| Échange de clés et KEMs | ECDH P-256, ECDH P-384, X25519, ML-KEM-512/768/1024 | key-exchange ou une fonctionnalité feuille |
| AEADs | AES-GCM, AES-GCM-SIV, AES-SIV-CMAC, ChaCha20-Poly1305, XChaCha20-Poly1305, AEGIS-256, Ascon-AEAD128 | aead 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.tomlliste 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
Debuget 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 chargeClone. 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.