sgcCrypto — eine moderne Kryptographiebibliothek für Delphi & C++ Builder

sgcCrypto_AES deckt CBC, GCM und CTR ab; sgcCrypto_Modes ergänzt ECB, OFB, CFB, Ciphertext-Stealing CTS, AES-CCM sowie AES Key Wrap / Key Wrap with Padding (RFC 3394 / 5649); sgcCrypto_CMAC ist AES-CMAC und AES-GMAC. sgcCrypto_ChaCha implementiert ChaCha20, XChaCha20, Salsa20 und XSalsa20, und sgcCrypto_Poly1305 kombiniert Poly1305 damit zu den AEAD-Chiffren ChaCha20-Poly1305 und XChaCha20-Poly1305 aus RFC 8439. AES-CCM ist die AEAD-Chiffre, die Zigbee, Bluetooth und die TLS-CCM-Suiten namentlich vorschreiben, da sie nichts über die Blockchiffre selbst hinaus benötigt, und CBC sowie ECB akzeptieren beide das Padding-Schema deiner Wahl, PKCS#7, ANSI X9.23, ISO 7816-4 und den Rest, für den Tag, an dem du lesen musst, was ein anderes System geschrieben hat. sgcAES_GCM_Decrypt und die Poly1305-Verifizierer vergleichen den Authentifizierungs-Tag in konstanter Zeit und verweigern die Rückgabe von Klartext bei einem fehlgeschlagenen Vergleich.

sgcCrypto_SHA2 und sgcCrypto_Keccak decken SHA-1/2, SHA-3, SHAKE, cSHAKE und KMAC ab; sgcCrypto_Blake2b und sgcCrypto_Blake2s ergänzen BLAKE2. sgcCrypto_HMAC ist Keyed Message Authentication. Um ein Passwort in einen Schlüssel zu verwandeln: sgcCrypto_KDF (PBKDF2), sgcCrypto_HKDF, sgcCrypto_Scrypt und sgcCrypto_Argon2, das alle drei Argon2-Varianten implementiert, d, i und id, den Gewinner der Password Hashing Competition. sgcCrypto_SipHash liefert dir einen schnellen Keyed Hash für Hashtable-Schlüssel, und sgcCrypto_TLSH ist ein Fuzzy Hash mit einer Ähnlichkeits-Distanzfunktion, kein kryptographischer Digest, nützlich zur Erkennung von Near-Duplicates.

sgcCrypto_Ed25519/Ed448 signieren und verifizieren; sgcCrypto_X25519/X448 übernehmen den passenden Diffie-Hellman-Austausch. sgcCrypto_ECCurves ergänzt ECDSA und ECDH über sieben Kurven, secp256k1, die drei Brainpool-Kurven und NIST P-256/P-384/P-521, mit deterministischen RFC-6979-Nonces und Signaturen in roher oder DER-Form, sowie BIP-340-Schnorr-Signierung obendrauf, mit den x-only-Public-Keys, die Taproot, Nostr und Lightning erwarten. sgcCrypto_EC ist das JOSE-orientierte Gegenstück: Signiere und verifiziere ein JWS direkt, ES256/384/512. sgcCrypto_RSA verifiziert PKCS#1-v1.5- und PSS-Signaturen direkt aus einem PEM-Schlüssel, und sgcCrypto_RSA_Keys geht weiter, mit Schlüsselerzeugung beliebiger Bitlänge, OAEP- und PKCS#1-v1.5-Verschlüsselung, sowie DER/PEM-Export sowohl in der PKCS#1- als auch der PKCS#8-Form BEGIN PRIVATE KEY. RSA- und EC-Schlüssel lassen sich ebenso leicht importieren wie exportieren, DER oder PEM, sodass ein einmal erzeugter Schlüssel gespeichert und wieder geladen werden kann, statt nur so lange zu leben wie der Prozess. sgcCrypto_ECIES rundet es mit hybrider Seal/Open-Verschlüsselung an einen X25519-Public-Key ab.

sgcCrypto_ASN1 liest DER und PEM und parst PKCS#1/SEC-1-Schlüssel; sgcCrypto_DER schreibt jeden Tag, den ein Zertifikat oder ein CSR braucht. sgcCrypto_X509 parst ein Zertifikat, verifiziert, dass es von einem gegebenen Aussteller signiert wurde, durchläuft und verifiziert eine Kette, verifiziert einen CSR, und parst eine CRL, um Widerruf zu prüfen. sgcCrypto_X509_Gen erzeugt ein selbstsigniertes Zertifikat oder einen PKCS#10-CSR von Grund auf, und eine CA stellt mit sgcX509_CreateSigned oder sgcX509_CreateSignedFromCSR aus: vollständiger Subject- und Issuer-Distinguished-Name, Gültigkeitsfenster, CA-Flag mit Pfadlängenbeschränkung, Key-Usage-Flags, Extended-Key-Usage-OIDs und Subject Alternative Names, einschließlich IP-Adress-SANs, die jetzt IPv6 in jeder Textform nach RFC 4291 annehmen, und URI-SANs für SPIFFE-artige Dienstidentitäten.

Signieren ist nicht mehr auf RSA und EC beschränkt. sgcX509_MLDSAKey und sgcX509_SLHDSAKey verpacken einen Post-Quanten-Schlüssel für sgcX509_CreateSelfSignedEx und sgcX509_CreateCSREx, sodass ein Zertifikat oder ein CSR mit ML-DSA oder SLH-DSA signiert werden kann. Eine CA kann außerdem einen ML-KEM-Public-Key zertifizieren (RFC 9935), der nicht signieren kann, sodass der Besitz auf anderem Weg nachgewiesen werden muss. Auf der Leseseite hat TsgcX509PublicKeyType x509pkMLDSA, x509pkSLHDSA und x509pkMLKEM dazubekommen, und sgcX509_VerifyChain erzwingt jetzt die basicConstraints-Pfadlänge und die nameConstraints-Erweiterung über dNSName, iPAddress, rfc822Name, uniformResourceIdentifier und directoryName, auf der Erzeugungsseite geschrieben aus PermittedDNSNames, ExcludedDNSNames, PermittedIPRanges und ExcludedIPRanges. Ein EC-Zertifikat kommt weiterhin etwa ein Drittel so groß heraus wie ein RSA-Zertifikat und verifiziert weit schneller, weshalb neue Deployments zu einem greifen.

sgcCrypto_MLKEM ist FIPS-203-Schlüsselkapselung, drei Parametersätze (ML-KEM-512/768/1024), mit impliziter Zurückweisung bei einem fehlerhaften Chiffretext. sgcCrypto_MLDSA ist FIPS-204-Signierung, ML-DSA-44/65/87. sgcCrypto_SLHDSA ist FIPS 205, alle sechs SHAKE-Parametersätze: 128s, 128f, 192s, 192f, 256s, 256f. Weil ML-KEM allein alles auf eine Gitter-Annahme setzt, die jünger ist als elliptische Kurven, kombiniert sgcCrypto_MLKEM_Hybrid ein X25519-Geheimnis und ein ML-KEM-Geheimnis zu einem gemeinsamen Schlüssel, sodass das Ergebnis nie schwächer ist als die klassische Hälfte, das Migrationsmuster, auf das sich die Branche gerade einigt.

Dieselbe Unit implementiert X-Wing (draft-connolly-cfrg-xwing-kem-10), X25519 mit ML-KEM-768 als ein einziges KEM: ein Public Key von 1216 Byte, ein Private Key von 32 Byte (der Seed), ein Chiffretext von 1120 Byte und ein Shared Secret von 32 Byte, über sgcXWing_GenerateKeyPair, sgcXWing_Encapsulate und sgcXWing_Decapsulate. Sie baut außerdem die TLS-1.3-Hybrid-Key-Shares aus RFC 10024 für X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 (IANA-Codepoints 0x11EC, 0x11EB und 0x11ED). Diese drei sind keine eigenständigen KEMs, sie bauen nur einen TLS-Key-Share.

Alle drei Algorithmen lesen und schreiben Schlüssel jetzt als X.509 SubjectPublicKeyInfo, PKCS#8 OneAsymmetricKey und PEM, sodass ein Post-Quanten-Schlüssel in denselben Dateien liegt wie ein RSA- oder EC-Schlüssel. ML-DSA- und ML-KEM-Private-Keys haben drei Formen, ausgewählt mit TsgcPQCPrivateKeyFormat: pqkfSeed schreibt nur den Seed (32 Byte bei ML-DSA, den 64 Byte langen d||z-Seed bei ML-KEM), pqkfExpanded schreibt den expandierten Schlüssel, pqkfBoth trägt beides. SLH-DSA hat eine einzige Private-Key-Form. sgcMLDSA_GenerateKeyPairAndSeed und sgcMLKEM_GenerateKeyPairAndSeed geben den Seed zusammen mit dem Schlüsselpaar zurück, sodass sich eine Datei in Seed-Form direkt nach der Erzeugung schreiben lässt.

sgcCrypto_OTP erzeugt und verifiziert HOTP- und TOTP-Codes, dieselben sechsstelligen Codes, die eine Authenticator-App anzeigt, mit einem konstantzeitigen Verifikationsfenster, das Uhrabweichung ausgleicht. sgcCrypto_Encoding hält die Hilfsfunktionen, die sich der Rest der Bibliothek teilt: konstantzeitiger Vergleich, sicheres Nullsetzen von Puffern, Hex, Base64url und Base32. sgcCrypto_Zip_AE2 implementiert die WinZip-AES-Verschlüsselung, AE-1 und AE-2, zum Verschlüsseln einzelner ZIP-Einträge. sgcCrypto_Random ist der plattformübergreifende CSPRNG hinter jedem Schlüssel und Nonce, der anderswo in der Bibliothek erzeugt wird, und sgcCrypto_Legacy hält MD4/MD5/HMAC-MD5/DES-ECB für die Interoperabilität mit älteren Formaten verfügbar, nicht für neue Designs.