sgcCrypto — une bibliothèque de cryptographie moderne pour Delphi et C++ Builder

sgcCrypto_AES couvre CBC, GCM et CTR ; sgcCrypto_Modes ajoute ECB, OFB, CFB, le ciphertext stealing CTS, AES-CCM, et l'AES Key Wrap / Key Wrap with Padding (RFC 3394 / 5649). sgcCrypto_CMAC est l'AES-CMAC et l'AES-GMAC. sgcCrypto_ChaCha implémente ChaCha20, XChaCha20, Salsa20 et XSalsa20, et sgcCrypto_Poly1305 associe Poly1305 avec eux pour former les chiffrements AEAD ChaCha20-Poly1305 et XChaCha20-Poly1305 de la RFC 8439. AES-CCM est l'AEAD que nomment Zigbee, Bluetooth et les suites TLS CCM, puisqu'il ne nécessite rien de plus que le chiffrement par bloc lui-même, et CBC comme ECB acceptent tous deux le schéma de remplissage de ton choix, PKCS#7, ANSI X9.23, ISO 7816-4 et les autres, pour le jour où tu dois lire ce qu'un autre système a écrit. sgcAES_GCM_Decrypt et les vérificateurs Poly1305 comparent le tag d'authentification en temps constant et refusent de renvoyer le texte clair quand la vérification échoue.

sgcCrypto_SHA2 et sgcCrypto_Keccak couvrent SHA-1/2, SHA-3, SHAKE, cSHAKE et KMAC ; sgcCrypto_Blake2b et sgcCrypto_Blake2s ajoutent BLAKE2. sgcCrypto_HMAC gère l'authentification par hachage à clé. Pour transformer un mot de passe en clé : sgcCrypto_KDF (PBKDF2), sgcCrypto_HKDF, sgcCrypto_Scrypt et sgcCrypto_Argon2, qui implémente les trois variantes d'Argon2, d, i et id, la gagnante de la Password Hashing Competition. sgcCrypto_SipHash te donne un hachage à clé rapide pour les clés de table de hachage, et sgcCrypto_TLSH est un hachage flou avec une fonction de distance de similarité, pas un condensé cryptographique, utile pour la détection de quasi-doublons.

sgcCrypto_Ed25519/Ed448 signent et vérifient ; sgcCrypto_X25519/X448 font le Diffie-Hellman correspondant. sgcCrypto_ECCurves ajoute ECDSA et ECDH sur sept courbes, secp256k1, les trois courbes Brainpool et NIST P-256/P-384/P-521, avec des nonces déterministes RFC 6979 et des signatures sous forme brute ou DER, plus la signature Schnorr BIP-340 en prime, avec les clés publiques x-only qu'attendent Taproot, Nostr et Lightning. sgcCrypto_EC est la variante orientée JOSE : signe et vérifie un JWS directement, ES256/384/512. sgcCrypto_RSA vérifie des signatures PKCS#1 v1.5 et PSS directement depuis une clé PEM, et sgcCrypto_RSA_Keys va plus loin avec la génération de clés à n'importe quelle longueur, le chiffrement OAEP et PKCS#1 v1.5, et l'export DER/PEM sous forme PKCS#1 et sous forme PKCS#8 BEGIN PRIVATE KEY. Les clés RSA et EC s'importent aussi facilement qu'elles s'exportent, en DER ou en PEM, si bien qu'une clé générée une fois peut être sauvegardée puis rechargée au lieu de ne vivre que le temps du processus. sgcCrypto_ECIES complète le tout avec le chiffrement hybride seal/open vers une clé publique X25519.

sgcCrypto_ASN1 lit le DER et le PEM et analyse les clés PKCS#1/SEC 1 ; sgcCrypto_DER écrit chaque tag dont un certificat ou une CSR a besoin. sgcCrypto_X509 analyse un certificat, vérifie qu'il a été signé par un émetteur donné, parcourt et vérifie une chaîne, vérifie une CSR, et analyse une CRL pour vérifier la révocation. sgcCrypto_X509_Gen génère un certificat autosigné ou une CSR PKCS#10 depuis zéro, et une AC émet avec sgcX509_CreateSigned ou sgcX509_CreateSignedFromCSR : nom distinctif complet du sujet et de l'émetteur, fenêtre de validité, indicateur d'AC avec contrainte de longueur de chemin, indicateurs d'usage de clé, OID d'usage étendu de clé et noms alternatifs du sujet, y compris les SAN d'adresse IP, qui acceptent désormais l'IPv6 sous toutes les formes textuelles de la RFC 4291, et les SAN d'URI pour les identités de service de type SPIFFE.

La signature n'est plus limitée à RSA et EC. sgcX509_MLDSAKey et sgcX509_SLHDSAKey enveloppent une clé post-quantique pour sgcX509_CreateSelfSignedEx et sgcX509_CreateCSREx, si bien qu'un certificat ou une CSR peut être signé avec ML-DSA ou SLH-DSA. Une AC peut aussi certifier une clé publique ML-KEM (RFC 9935), qui ne sait pas signer, la possession doit donc être prouvée autrement. Du côté de la lecture, TsgcX509PublicKeyType a gagné x509pkMLDSA, x509pkSLHDSA et x509pkMLKEM, et sgcX509_VerifyChain applique désormais la longueur de chemin de basicConstraints et l'extension nameConstraints sur dNSName, iPAddress, rfc822Name, uniformResourceIdentifier et directoryName, écrite du côté de la génération depuis PermittedDNSNames, ExcludedDNSNames, PermittedIPRanges et ExcludedIPRanges. Un certificat EC ressort toujours environ trois fois plus petit qu'un certificat RSA et se vérifie bien plus vite, ce qui explique pourquoi les nouveaux déploiements y ont recours.

sgcCrypto_MLKEM est l'encapsulation de clé FIPS 203, trois jeux de paramètres (ML-KEM-512/768/1024), avec rejet implicite sur un texte chiffré malformé. sgcCrypto_MLDSA est la signature FIPS 204, ML-DSA-44/65/87. sgcCrypto_SLHDSA est FIPS 205, les six jeux de paramètres SHAKE : 128s, 128f, 192s, 192f, 256s, 256f. Comme ML-KEM à lui seul mise tout sur une hypothèse de réseau euclidien plus jeune que les courbes elliptiques, sgcCrypto_MLKEM_Hybrid combine un secret X25519 et un secret ML-KEM en une seule clé partagée, si bien que le résultat n'est jamais plus faible que la moitié classique, le schéma de migration vers lequel converge l'industrie.

La même unité implémente X-Wing (draft-connolly-cfrg-xwing-kem-10), X25519 avec ML-KEM-768 comme un seul KEM : une clé publique de 1216 octets, une clé privée de 32 octets (la graine), un texte chiffré de 1120 octets et un secret partagé de 32 octets, via sgcXWing_GenerateKeyPair, sgcXWing_Encapsulate et sgcXWing_Decapsulate. Elle construit aussi les parts de clé hybrides TLS 1.3 de la RFC 10024 pour X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024 (points de code IANA 0x11EC, 0x11EB et 0x11ED). Ces trois-là ne sont pas des KEM autonomes, ils ne servent qu'à construire une part de clé TLS.

Les trois algorithmes lisent et écrivent désormais les clés en X.509 SubjectPublicKeyInfo, en PKCS#8 OneAsymmetricKey et en PEM, si bien qu'une clé post-quantique vit dans les mêmes fichiers qu'une clé RSA ou EC. Les clés privées ML-DSA et ML-KEM ont trois formes, choisies avec TsgcPQCPrivateKeyFormat : pqkfSeed écrit la graine seule (32 octets pour ML-DSA, la graine d||z de 64 octets pour ML-KEM), pqkfExpanded écrit la clé développée, pqkfBoth porte les deux. SLH-DSA n'a qu'une seule forme de clé privée. sgcMLDSA_GenerateKeyPairAndSeed et sgcMLKEM_GenerateKeyPairAndSeed renvoient la graine en même temps que la paire de clés, de sorte qu'un fichier au format graine peut être écrit juste après la génération.

sgcCrypto_OTP génère et vérifie les codes HOTP et TOTP, les mêmes codes à six chiffres qu'affiche une application d'authentification, avec une fenêtre de vérification en temps constant qui absorbe le décalage d'horloge. sgcCrypto_Encoding regroupe les fonctions utilitaires que partage le reste de la bibliothèque : comparaison en temps constant, effacement sécurisé de buffer, hex, Base64url et Base32. sgcCrypto_Zip_AE2 implémente le chiffrement WinZip AES, AE-1 et AE-2, pour chiffrer des entrées ZIP individuelles. sgcCrypto_Random est le CSPRNG multiplateforme derrière chaque clé et nonce générés ailleurs dans la bibliothèque, et sgcCrypto_Legacy garde MD4/MD5/HMAC-MD5/DES-ECB disponibles pour l'interopérabilité avec des formats plus anciens, pas pour de nouvelles conceptions.