Alles, was sgcCrypto kann, aufgeschlüsselt über die 43 Units auf der Festplatte. Es gibt hier keine Komponenten und keine Design-Time-Eigenschaften: Jede Zeile unten ist eine Funktion oder Prozedur, die du direkt aufrufst. Vollständiger Quellcode ist bei jeder Lizenz dabei. Die Sprungmarken unten führen dich zu den sechs Fähigkeitsfamilien, in die die Units fallen, plus zur TLS-1.3- und TLS-1.2-Engine, die dasselbe Paket darauf aufbaut.
sgcCrypto hat keine Komponenten. Die 43 Units unten exportieren einfache Funktionen, es gibt keine Tsgc*-Klasse und keine sgcCrypto_Reg.pas. Füge eine Unit zu deiner uses-Klausel hinzu und rufe die Funktion auf.
Bereits enthalten. sgcCrypto ist bei sgcWebSockets Standard, Professional und Enterprise sowie bei All-Access kostenlos dabei. Es wird auch eigenständig verkauft (mit gebündelter sgcWebSockets-Core-Runtime) für Kunden, die nur Core besitzen. Siehe Preise.
AES, CCM, ChaCha20, Poly1305, 5 Units
SHA-2/3, BLAKE2, Argon2, 11 Units
Ed25519, X25519, Schnorr, RSA, 10 Units
X.509, ASN.1, RSA & EC CSR, 5 Units
ML-KEM, ML-DSA, SLH-DSA, 6 Units
HOTP/TOTP, Kodierung, ZIP-AES, 6 Units
iohNativeTLS, X25519MLKEM768, reines Pascal
Jede sgcCrypto_*.pas-Unit unter sgcWebSockets/delphi/Source/, gruppiert nach Familie.
| Unit | Familie | Was sie macht |
|---|---|---|
sgcCrypto_AES | Symmetrisch | AES-CBC, AES-GCM (AEAD), AES-CTR. |
sgcCrypto_Modes | Symmetrisch | AES-ECB, OFB, CFB, CTS, CCM (AEAD), Key Wrap / Key Wrap with Padding, sowie die sieben Padding-Schemata. |
sgcCrypto_CMAC | Symmetrisch | AES-CMAC- und AES-GMAC-Nachrichtenauthentifizierung. |
sgcCrypto_ChaCha | Symmetrisch | ChaCha20, XChaCha20, Salsa20, XSalsa20. |
sgcCrypto_Poly1305 | Symmetrisch | Poly1305-MAC, ChaCha20-Poly1305 und XChaCha20-Poly1305 AEAD. |
sgcCrypto_SHA2 | Hashing & KDF | SHA-1, SHA-224, SHA-256, SHA-384, SHA-512. |
sgcCrypto_Keccak | Hashing & KDF | SHA-3, SHAKE128/256, cSHAKE, KMAC. |
sgcCrypto_Blake2b | Hashing & KDF | BLAKE2b, mit oder ohne Schlüssel. |
sgcCrypto_Blake2s | Hashing & KDF | BLAKE2s, mit oder ohne Schlüssel. |
sgcCrypto_HMAC | Hashing & KDF | HMAC-SHA1/256/384/512. |
sgcCrypto_KDF | Hashing & KDF | PBKDF2, KDF1, KDF2 und X9.63, wählbarer Hash. |
sgcCrypto_HKDF | Hashing & KDF | HKDF Extract-and-Expand. |
sgcCrypto_Scrypt | Hashing & KDF | scrypt, speicherharte KDF. |
sgcCrypto_Argon2 | Hashing & KDF | Argon2d, Argon2i, Argon2id. |
sgcCrypto_SipHash | Hashing & KDF | SipHash-2-4 Keyed Hash. |
sgcCrypto_TLSH | Hashing & KDF | TLSH Fuzzy Hash und Ähnlichkeits-Diff. |
sgcCrypto_Ed25519 | Signaturen & Schlüsselaustausch | Ed25519 signieren / verifizieren. |
sgcCrypto_X25519 | Signaturen & Schlüsselaustausch | X25519 Diffie-Hellman. |
sgcCrypto_Ed448 | Signaturen & Schlüsselaustausch | Ed448 signieren / verifizieren. |
sgcCrypto_X448 | Signaturen & Schlüsselaustausch | X448 Diffie-Hellman. |
sgcCrypto_GF448 | Signaturen & Schlüsselaustausch | Interne GF(2^448-2^224-1)-Körperarithmetik für Ed448/X448. |
sgcCrypto_ECCurves | Signaturen & Schlüsselaustausch | ECDSA / ECDH über secp256k1, Brainpool P256r1/P384r1/P512r1 und NIST P-256/P-384/P-521, DER-Signaturen, Schlüsselexport/-import und BIP-340-Schnorr. |
sgcCrypto_EC | Signaturen & Schlüsselaustausch | Allgemeines EC-Signieren/-Verifizieren als JWS (ES256/384/512), ECDH. |
sgcCrypto_RSA | Signaturen & Schlüsselaustausch | RSA PKCS#1-v1.5-Signieren, PKCS#1-v1.5-/PSS-Verifizieren, aus PEM oder roh. |
sgcCrypto_RSA_Keys | Signaturen & Schlüsselaustausch | RSA-Schlüsselerzeugung, OAEP (mit unabhängigem MGF1-Hash), PSS, PKCS#1-v1.5-Signieren/-Verifizieren/-Verschlüsseln/-Entschlüsseln, PKCS#1- und PKCS#8-DER/PEM-Export und -Import. |
sgcCrypto_ECIES | Signaturen & Schlüsselaustausch | ECIES-Seal-/-Open-Hybridverschlüsselung über X25519. |
sgcCrypto_ASN1 | PKI | DER-Reader, PEM-Codec, PKCS#1-/SEC-1-Schlüsselparsing. |
sgcCrypto_DER | PKI | DER-Writer-Primitiven. |
sgcCrypto_BigInteger | PKI | Interne Arithmetik mit beliebiger Genauigkeit. |
sgcCrypto_X509 | PKI | X.509 parsen, verifizieren, Kette mit pathLenConstraint und nameConstraints, CSR verifizieren, CRL, Widerruf. Liest RSA-, EC-, Ed25519-, ML-DSA-, SLH-DSA- und ML-KEM-Public-Keys. |
sgcCrypto_X509_Gen | PKI | Erzeugung selbstsignierter Zertifikate, CA-ausgestellter Zertifikate und PKCS#10-CSRs, signiert mit RSA, EC, ML-DSA oder SLH-DSA, mit URI- und IPv6-Subject-Alternative-Names sowie nameConstraints. |
sgcCrypto_MLKEM | Post-Quanten | ML-KEM-Schlüsselkapselung (FIPS 203), 3 Parametersätze, mit Schlüsselimport und -export als SubjectPublicKeyInfo, PKCS#8 und PEM. |
sgcCrypto_MLKEM_Poly | Post-Quanten | Interne Polynomring-Arithmetik hinter ML-KEM. |
sgcCrypto_MLKEM_Hybrid | Post-Quanten | Hybride X25519- + ML-KEM-Schlüsselkapselung, X-Wing, sowie die TLS-1.3-Hybrid-Key-Shares aus RFC 10024. |
sgcCrypto_MLDSA | Post-Quanten | ML-DSA-Digitalsignaturen (FIPS 204), 3 Parametersätze, mit Schlüsselimport und -export als SubjectPublicKeyInfo, PKCS#8 und PEM. |
sgcCrypto_MLDSA_Poly | Post-Quanten | Interne Polynomring-Arithmetik hinter ML-DSA. |
sgcCrypto_SLHDSA | Post-Quanten | SLH-DSA-Signaturen (FIPS 205), 6 SHAKE-Parametersätze, mit Schlüsselimport und -export als SubjectPublicKeyInfo, PKCS#8 und PEM. |
sgcCrypto_OTP | OTP & Sonstiges | HOTP, TOTP, konstantzeitiges Verifikationsfenster. |
sgcCrypto_Encoding | OTP & Sonstiges | Konstantzeitiger Vergleich, sicheres Nullsetzen, Hex/Base64url/Base32. |
sgcCrypto_Zip_AE2 | OTP & Sonstiges | WinZip-AES-Verschlüsselung für ZIP-Einträge, AE-1 / AE-2. |
sgcCrypto_Legacy | OTP & Sonstiges | MD4, MD5, HMAC-MD5, DES-ECB, RIPEMD-160 und HMAC-RIPEMD160, nur für Interoperabilität. |
sgcCrypto_Random | OTP & Sonstiges | Plattformübergreifender CSPRNG. |
sgcCrypto_Int64 | OTP & Sonstiges | Interne 64-Bit-Integer-Emulation für Delphi 7. |
AES in den Modi, die Produktionscode tatsächlich nutzt, plus die ChaCha20-/Poly1305-AEAD-Familie.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| AES-CBC | sgcAES_CBC_Encrypt / sgcAES_CBC_Decrypt | PKCS#7-Padding, 16-Byte-IV. Die Schlüssellänge wählt die Chiffre: 16/24/32 Byte = AES-128/192/256. |
| AES-CBC, ohne Padding | sgcAES_CBC_Encrypt_NoPad / sgcAES_CBC_Decrypt_NoPad | Der Modus, den Java als AES/CBC/NoPadding schreibt. Die Eingabe muss bereits ein Vielfaches von 16 Byte sein; eine nicht ausgerichtete Eingabe löst eine Exception aus, statt still aufgefüllt zu werden zu etwas, das die Gegenseite nicht lesen kann. |
| AES-GCM (AEAD) | sgcAES_GCM_Encrypt / sgcAES_GCM_Decrypt | Empfohlen: 12-Byte-IV. 16-Byte-Tag, in konstanter Zeit verglichen; Decrypt gibt bei fehlgeschlagenem Tag False und leeren Klartext zurück. |
| AES-Kern | sgcAES_GetCore / sgcAES_SetCore | aescConstantTime ist der Standard, ein Bitsliced-Kern, der den Speicher nie mit einem geheimen Byte indiziert und nie danach verzweigt, was den Cache-Timing-Kanal auf Schlüssel und Klartext schließt. aescTable ist der klassische Tabellenkern, der über den Datencache leckt und in jeder Messung langsamer war, weshalb er nur als Rückfall erhalten bleibt. GHASH, das GCM authentifiziert, multipliziert unter einer Maske, statt nach dem Schlüssel zu verzweigen. Setze den Kern einmal beim Start, bevor ein Worker-Thread läuft. |
| AES-CCM (AEAD) | sgcAES_CCM_Encrypt / sgcAES_CCM_Decrypt | Die AEAD-Chiffre, die ressourcenbeschränkte und IoT-Stacks vorschreiben, Zigbee, 802.15.4, Bluetooth und die TLS-CCM-Suiten, weil sie nur die Blockchiffre und keine GHASH-Tabelle benötigt. Nonce 7 bis 13 Byte, Tag 4 bis 16 Byte, in konstanter Zeit verifiziert. |
| AES-CTR | sgcAES_CTR | SRTP-artiges AES-CM (RFC 3711). Symmetrischer Aufruf, kein Padding, 128-Bit-Big-Endian-Zähler. |
| AES-ECB | sgcAES_ECB_Encrypt / sgcAES_ECB_Decrypt | Kein IV, kein Chaining. Enthalten zur Interoperabilität mit Formaten, die es vorschreiben. |
| Padding-Schemata | sgcPad_Add / sgcPad_Remove, sgcAES_CBC_EncryptPad / DecryptPad, sgcAES_ECB_EncryptPad / DecryptPad | TsgcPadding deckt None, PKCS#7, Zero, ANSI X9.23, ISO 7816-4, ISO 10126-2 und TBC ab, sodass CBC und ECB Daten aus einem System lesen und schreiben können, das sich nicht für PKCS#7 entschieden hat. sgcPad_Remove gibt bei jeder Art von fehlerhaftem Padding False über denselben Pfad zurück. |
| AES-OFB / AES-CFB | sgcAES_OFB, sgcAES_CFB_Encrypt / sgcAES_CFB_Decrypt | Feedback-Modi im Stream-Cipher-Stil. |
| AES-CTS | sgcAES_CTS_Encrypt / sgcAES_CTS_Decrypt | Ciphertext Stealing: verschlüsselt Daten, die kein Vielfaches der Blockgröße sind, ohne Padding-Overhead. |
| AES Key Wrap | sgcAES_KeyWrap / sgcAES_KeyUnwrap | RFC 3394, zum Verpacken eines Schlüssels unter einem anderen. |
| AES Key Wrap with Padding | sgcAES_KeyWrapPad / sgcAES_KeyUnwrapPad | RFC 5649, für Schlüsselmaterial, das kein Vielfaches von 8 Byte ist. |
| AES-CMAC | sgcAES_CMAC / sgcAES_CMAC_Verify | RFC 4493 Nachrichtenauthentifizierungscode. |
| AES-GMAC | sgcAES_GMAC / sgcAES_GMAC_Verify | Der reine Authentifizierungsmodus von GCM: Die gesamte Nachricht wird als zusätzliche Daten übertragen, nichts wird verschlüsselt. Der IV darf unter einem Schlüssel niemals wiederholt werden, und der 16-Byte-Tag wird in konstanter Zeit verglichen. |
| Low-Level-Blockprimitiven | sgcAES_ExpandKey, sgcAES_EncryptBlock, sgcAES_DecryptBlock | Für die obigen Modus- und MAC-Units freigelegt; direkt aufrufen nur, um einen noch nicht bereitgestellten Modus zu bauen. |
| ChaCha20 | sgcChaCha20 | RFC 8439, 96-Bit-Nonce, 32-Bit-Zähler. |
| XChaCha20 | sgcXChaCha20 | 192-Bit-erweiterte Nonce, sicher für zufällige Nonce-Erzeugung in großem Umfang. |
| Salsa20 / XSalsa20 | sgcSalsa20 / sgcXSalsa20 | Die Vorgänger-Stream-Cipher-Familie, beide Nonce-Größen. |
| Subkey-Ableitung | sgcHChaCha20 / sgcHSalsa20 | Was die X-Varianten intern nutzen, um einen Subkey aus den ersten 16 Nonce-Bytes abzuleiten. |
| Poly1305-MAC | sgcPoly1305 / sgcPoly1305_Verify | Einmal-Authentifikator, RFC 8439. Einen Poly1305-Schlüssel nie wiederverwenden. |
| ChaCha20-Poly1305 AEAD | sgcChaCha20Poly1305_Encrypt / _Decrypt | Die AEAD-Chiffre hinter der zweiten Cipher-Suite von TLS 1.3 und SSH. |
| XChaCha20-Poly1305 AEAD | sgcXChaCha20Poly1305_Encrypt / _Decrypt | Dieselbe AEAD, 192-Bit-Nonce, die Konstruktion, die libsodium crypto_aead_xchacha20poly1305_ietf nennt. |
Jede gängige Hash-Familie, plus PBKDF2, HKDF, scrypt und alle drei Argon2-Varianten.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| SHA-1 / SHA-2 | sgcSHA1, sgcSHA224, sgcSHA256, sgcSHA384, sgcSHA512 | FIPS 180-4. SHA-1 bleibt aus Interoperabilitätsgründen erhalten, nicht empfohlen für neue Signaturen. |
| SHA-3 | sgcSHA3_224 / _256 / _384 / _512 | FIPS 202, der Keccak-Schwamm, strukturell unabhängig von SHA-2. |
| SHAKE128 / SHAKE256 | sgcSHAKE128 / sgcSHAKE256 | Extendable-Output-Funktionen: fordere jede beliebige Digest-Länge an. |
| cSHAKE128 / cSHAKE256 | sgcCSHAKE128 / sgcCSHAKE256 | Domain-getrenntes SHAKE, NIST SP 800-185, die Basis für KMAC. |
| KMAC128 / KMAC256 | sgcKMAC128 / sgcKMAC256 | Keccak-basierter MAC mit variabler Ausgabelänge. |
| BLAKE2b | sgcBlake2b / sgcBlake2b_Keyed | RFC 7693, Digests bis zu 64 Byte, eingebautes Keying (keine separate HMAC nötig). |
| BLAKE2s | sgcBlake2s / sgcBlake2s_Keyed | RFC 7693, Digests bis zu 32 Byte, optimiert für 32-Bit-Plattformen. |
| Streaming-Digests | sgcBlake2b_Init/_Update/_Final, entsprechende Aufrufe für Keccak/Blake2s | Zum Hashen von Daten, die zu groß sind, um sie auf einmal im Speicher zu halten. |
| HMAC | sgcHMAC_SHA1 / _SHA256 / _SHA384 / _SHA512 | RFC 2104 Keyed Hashing über die SHA-1/2-Familie. |
| RIPEMD-160 / HMAC-RIPEMD160 | sgcRIPEMD160, sgcHMAC_RIPEMD160 | ISO/IEC 10118-3 und RFC 2286. Das 160-Bit-Digest, über das Bitcoin-Adressen SHA-256 schichten, und das, das OpenPGP namentlich vorschreibt. |
| PBKDF2 | sgcPBKDF2, sgcPBKDF2_SHA1 / _SHA256 / _SHA512 | RFC 8018. Nur mäßig speicherhart; bevorzuge Argon2id oder scrypt, wenn du wählen kannst. |
| HKDF | sgcHKDF_Extract_SHA256 / _SHA384, sgcHKDF_Expand_SHA256 / _SHA384, sgcHKDF_SHA256 / _SHA384 | RFC 5869, Extract-then-Expand-Schlüsselableitung, der Standardweg, ein geteiltes Geheimnis in mehrere Schlüssel zu verwandeln. |
| KDF1 / KDF2 / X9.63 | sgcKDF1, sgcKDF2, sgcKDF_X963 | Die Zähler-basierten Ableitungen, die ISO 18033-2, IEEE 1363a und ANSI X9.63 definieren, das, was RSA-KEM und ECIES namentlich vorschreiben. KDF1 zählt ab 0 und KDF2 ab 1, ein Unterschied, der reale Interoperabilitätsfehler verursacht hat, prüfe daher, welche der beiden deine Spezifikation meint. |
| scrypt | sgcScrypt | RFC 7914, speicherhart, widersteht GPU-/ASIC-Angriffen weit besser als PBKDF2. |
| Argon2 | sgcArgon2 (d / i / id), sgcArgon2id-Komfortwrapper | RFC 9106, der Gewinner der Password Hashing Competition. Vollständige Schnittstelle mit optionalem Secret (Pepper) und Associated Data. |
| SipHash-2-4 | sgcSipHash24 / sgcSipHash24_Value | Schnelle Keyed PRF für Hashtable-Schlüssel, widersteht Hash-Flooding-Denial-of-Service. |
| TLSH Fuzzy Hash | sgcTLSH, sgcTLSH_Init/_Update/_Final | Lokalitätssensitiver Hash zur Erkennung von Near-Duplicates, kein kryptographischer Digest. |
| TLSH-Ähnlichkeitswert | sgcTLSH_Diff | Distanz zwischen zwei TLSH-Digests; kleiner bedeutet ähnlicher. |
Signiere, verifiziere und leite gemeinsame Geheimnisse über fünf unterschiedliche Kurvenfamilien plus RSA ab.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| Ed25519 Signieren / Verifizieren | sgcEd25519_Sign / sgcEd25519_Verify, sgcEd25519_PublicKey | RFC 8032. Öffentlicher Schlüssel mit 32 Byte, Signatur mit 64 Byte. Verify weist nicht kanonische Punkte und S >= L gemäß Abschnitt 5.1.7 zurück. Das Signieren läuft in konstanter Zeit im geheimen Skalar und in der Nonce pro Nachricht: feste Vier-Bit-Fenster, der Tabelleneintrag wird durch Durchlaufen aller sechzehn unter einer Maske gewählt, und die vollständige Additionsformel aus Abschnitt 5.1.4. Der öffentliche Schlüssel stammt aus dem 32-Byte-Seed. |
| X25519-Schlüsselaustausch | sgcX25519, sgcX25519_PublicKey, sgcX25519_SharedSecret | RFC 7748 Diffie-Hellman über Curve25519. |
| Ed448 signieren / verifizieren | sgcEd448_GenerateKeyPair, sgcEd448_Sign, sgcEd448_Verify | RFC 8032, die 448-Bit-EdDSA-Kurve (Goldilocks). |
| X448-Schlüsselaustausch | sgcX448, sgcX448_PublicKey, sgcX448_SharedSecret | RFC 7748 Diffie-Hellman über Curve448. |
| secp256k1 | sgcECDSA_SignHash / VerifyHash mit eccSecp256k1 | Die Bitcoin-/Ethereum-Kurve, SEC 2, in sgcCrypto_ECCurves. |
| Brainpool P256r1 / P384r1 / P512r1 | dieselben Funktionen mit eccBrainpoolP256r1 / P384r1 / P512r1 | RFC 5639, verbreitet in EU-eIDAS- und Behördenprofilen. |
| NIST P-256 / P-384 / P-521 | dieselben Funktionen mit eccP256 / eccP384 / eccP521 | TsgcECCurve benennt jetzt sieben Kurven, sodass Schlüsselerzeugung, Signieren, Verifizieren, ECDH und Punktkompression alle die NIST-Primkurven aus rohen Schlüssel-Bytes erreichen, nicht nur aus einer PEM-Datei. |
| Deterministische ECDSA-Nonce | eingebaut in sgcECDSA_SignHash | RFC 6979: Die Nonce wird aus dem privaten Schlüssel und der Nachricht abgeleitet, kein RNG-Fehlermodus. |
| Skalarmultiplikation in konstanter Zeit | innerhalb von sgcECDSA_SignHash, sgcECDH_SharedSecret und der EC-Schlüsselerzeugung | Jede Kurve in sgcCrypto_ECCurves läuft auf derselben Engine: Montgomery-Reduktion, die keinen datenabhängigen Schritt hat, ein festes Fenster, dessen Anzahl von der Kurve kommt, Tabelleneinträge, die durch Durchlaufen aller unter einer Maske gewählt werden, und eine vollständige Additionsformel, die nie eine Koordinate ansieht, um zu entscheiden, welcher Fall gilt. Die JOSE-, WebAuthn- und E2EE-Pfade von sgcCrypto_EC führen denselben Code aus. |
| ECDH (secp256k1 / Brainpool) | sgcECDH_SharedSecret | Gemeinsames Geheimnis über dieselben vier Kurven. |
| Punktkompression | sgcEC_Compress / sgcEC_Decompress | Speichere oder übertrage die kürzere komprimierte Public-Key-Form. |
| EC als JWS (ES256/384/512) | sgcECDSA_SignJWS / sgcECDSA_VerifyJWS | Kurve automatisch aus der angeforderten Bitlänge gewählt, direkt aus einem PEM-Schlüssel signieren/verifizieren, JOSE-orientiertes Gegenstück zu ECCurves. |
| Generisches ECDH | sgcECDH | Gemeinsames Geheimnis aus einem rohen privaten Schlüssel und dem öffentlichen Punkt der Gegenseite. |
| Rohes / DER-ECDSA-Verify | sgcECDSA_VerifyRaw / sgcECDSA_VerifyDER | Verifiziert gegen ein rohes (Qx, Qy, r, s)-Tupel oder eine DER-kodierte Signatur. |
| DER-ECDSA-Signieren & -Konvertierung | sgcECDSA_SignDER / sgcECDSA_VerifyDER, sgcECDSA_RawToDER / sgcECDSA_DERToRaw | X.509, CMS und TLS tragen den DER-ECDSA-Sig-Value, eine SEQUENCE aus INTEGER r gefolgt von INTEGER s. JOSE und WebAuthn tragen stattdessen das rohe Paar R || S. Signiere direkt in eine der beiden Formen, oder konvertiere eine bestehende Signatur zwischen ihnen. |
| Schnorr-Signaturen (BIP-340) | sgcSchnorr_PublicKey, sgcSchnorr_Sign, sgcSchnorr_Verify | Nur secp256k1, mit x-only 32-Byte-Public-Keys und 64-Byte-Signaturen: was Taproot, Nostr und Lightning verwenden. sgcSchnorr_TaggedHash ist freigelegt, damit sich die BIP-341- und BIP-342-Tags auf derselben Konstruktion aufbauen lassen. |
| RSA signieren (PKCS#1 v1.5) | sgcRSA_SignPKCS1 | Aus einem PEM-Private-Key, SHA-1/256/384/512-Digest. |
| Private RSA-Schlüsseloperationen | sgcRSA_SignPKCS1 und die übrigen Signier- und Entschlüsselungsaufrufe von sgcCrypto_RSA_Keys | Jede Operation wird mit einem frischen Zufallspaar geblendet, über eine Exponentiation mit festem Fenster und eine CRT-Rekombination geführt, deren Laufzeit nicht von den Faktoren oder den Daten abhängt, und gegen den öffentlichen Exponenten geprüft, bevor das Ergebnis zurückgegeben wird. Ein Fehler in einer CRT-Hälfte würde sonst in einer einzigen Signatur einen Faktor verraten, daher wird bei einer Abweichung nichts zurückgegeben. |
| RSA verifizieren (PKCS#1 v1.5 / PSS) | sgcRSA_VerifyPKCS1, sgcRSA_VerifyPSS, sowie _Raw-Varianten über Modulus/Exponent | RFC 8017. Verify funktioniert aus einem PEM-Schlüssel oder rohem Modulus und Exponent, ohne Konstruktion eines Key-Objekts. |
| RSA-Schlüsselerzeugung | sgcRSA_GenerateKey | Jede angeforderte Bitlänge, Miller-Rabin-Primzahltest. |
| RSA-OAEP-Verschlüsselung | sgcRSA_OAEP_Encrypt / sgcRSA_OAEP_Decrypt | RFC 8017 Optimal Asymmetric Encryption Padding. |
| RSA-OAEP mit unabhängigem MGF1-Hash | die fünf-Parameter-Überladungen von sgcRSA_OAEP_Encrypt / sgcRSA_OAEP_Decrypt | Lege den Label-Hash und den MGF1-Hash getrennt fest. OAEPWithSHA256AndMGF1Padding bedeutet in Bouncy Castle SHA-256 für beide, aber in SunJCE SHA-256 mit MGF1-SHA1, und genau dieser Fehlabgleich ist der übliche Grund, warum die Java-Interoperabilität scheitert. |
| RSA-PKCS#1-v1.5-Verschlüsselung | sgcRSA_PKCS1_Encrypt / sgcRSA_PKCS1_Decrypt | RFC 8017 Abschnitt 7.2, der Modus, den Java RSA/ECB/PKCS1Padding nennt. Decrypt nimmt für jeden Fehler denselben Pfad, sodass es einem Padding-Oracle nichts liefert, womit es arbeiten könnte. Bevorzuge OAEP für alles Neue. |
| RSA-PSS-/PKCS#1-Signierung | sgcRSA_PSS_Sign / Verify, sgcRSA_PKCS1_Sign / Verify | Signiere direkt aus einem erzeugten TsgcRSAPrivateKey. |
| RSA-Schlüsselexport | sgcRSA_ExportPrivateKeyPEM, sgcRSA_ExportPublicKeyPEM, entsprechende DER-Aufrufe | PKCS#1- und SubjectPublicKeyInfo-Kodierungen. |
| PKCS#8- und SEC-1-Schlüsselexport | sgcRSA_ExportPrivateKeyPKCS8DER / PKCS8PEM, sgcEC_ExportPrivateKeyPKCS8DER / PKCS8PEM, sgcEC_ExportPrivateKeySEC1DER / SEC1PEM, sgcEC_ExportSubjectPublicKeyInfo, sgcEC_ExportPublicKeyPEM | Der Container BEGIN PRIVATE KEY, den Java, .NET und die meisten modernen Tools erwarten, neben der SEC-1-Form BEGIN EC PRIVATE KEY und dem SubjectPublicKeyInfo, das ein Zertifikat einbettet. Unverschlüsselt, das Ergebnis ist also blankes Schlüsselmaterial. |
| RSA- und EC-Schlüsselimport | sgcRSA_ImportPrivateKeyDER / PEM, sgcRSA_ImportPublicKeyDER / PEM, sgcEC_ImportPrivateKeyDER / PEM, sgcEC_ImportPublicKeyDER / PEM | Das gab es vorher nicht: Ein erzeugter Schlüssel ließ sich schreiben, aber nie wieder einlesen. Der Import akzeptiert PKCS#1, PKCS#8, SEC 1 und SubjectPublicKeyInfo, DER oder PEM, berechnet die CRT-Parameter oder den öffentlichen Punkt neu, wenn die Datei sie auslässt, und gibt bei fehlerhafter Eingabe False zurück, statt eine Exception auszulösen, sodass sich nicht vertrauenswürdige Dateien gefahrlos übergeben lassen. |
| ECIES Seal / Open | sgcECIES_GenerateKeyPair, sgcECIES_Seal, sgcECIES_Open | Hybridverschlüsselung an einen X25519-Public-Key: ephemeres ECDH plus ein AEAD, ein Aufruf pro Richtung. |
Lies ein Zertifikat, das jemand anderes ausgestellt hat, oder erzeuge selbst eines, mit einem DER-Encoder und -Decoder unter beidem.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| DER-Reader | sgcASN1_Read, sgcASN1_Next, sgcASN1_Content | Durchläuft eine DER-Struktur Knoten für Knoten. |
| Striktes DER | sgcASN1_Read, sgcASN1_IsMinimalUnsignedInteger | Jede Struktur, die die Unit liest, ist per Spezifikation DER, daher werden Längen an die DER-Regeln gebunden: Die unbestimmte Form wird abgelehnt, ebenso eine lange Form, die die kurze Form hätte tragen können. Eine ECDSA-Signatur, deren INTEGER nicht minimal kodiert sind, wird ebenfalls abgelehnt, sodass eine Signatur nicht auf zwei Arten geschrieben und für zwei verschiedene Werte gehalten werden kann. |
| PEM-Codec | sgcPEM_Decode / sgcPEM_Encode | RFC 7468, der -----BEGIN ... -----END-Wrapper um DER. |
| RSA-Schlüssel-Parsing | sgcASN1_ParseRSAPrivateKey / PublicKey | PKCS#1- (RFC 8017) Schlüsselstrukturen. |
| EC-Schlüssel-Parsing | sgcASN1_ParseECPrivateKey / PublicKey | SEC-1-Schlüsselstrukturen. |
| DER-Writer, strukturell | sgcDER_Sequence, sgcDER_Set, sgcDER_Tagged, sgcDER_ContextExplicit / Implicit | Die Bausteine, aus denen jedes Zertifikatsfeld zusammengesetzt wird. |
| DER-Writer, Werte | sgcDER_Integer, sgcDER_OctetString, sgcDER_BitString, sgcDER_Boolean, sgcDER_Null | Primitive Wert-Encoder. |
| DER-Writer, Strings & Identifikatoren | sgcDER_OID, sgcDER_UTF8String, sgcDER_PrintableString, sgcDER_IA5String, sgcDER_Time | Objektbezeichner, die drei String-Typen, die X.509 verwendet, sowie UTCTime/GeneralizedTime. |
| Zertifikats-Parsing | sgcX509_Parse | Vollständige Zertifikatsstruktur: Subject, Issuer, Gültigkeit, Public Key, Erweiterungen. |
| Signatur-/Ketten-Verifikation | sgcX509_VerifySignedBy, sgcX509_VerifyChain | Verifiziere ein Zertifikat gegen einen Aussteller, oder durchlaufe und verifiziere ein Array von DER-Zertifikaten. |
| CRL-Parsing & Widerruf | sgcX509_CRL_Parse, sgcX509_IsRevoked, sgcX509_CRL_VerifySignedBy | Parst eine Certificate Revocation List und prüft eine Seriennummer dagegen. |
| Namensformatierung | sgcX509_SubjectRFC2253, sgcX509_IssuerRFC2253, sgcX509_SubjectOneLine | RFC-2253-Distinguished-Name-Strings, für Logging und Anzeige. |
| Erweiterungen & SANs | sgcX509_GetExtension, sgcX509_GetCRLDistributionURIs | Liest beliebige Erweiterungs-OIDs und CRL-Distribution-Point-URIs. |
| Erzeugung selbstsignierter Zertifikate | sgcX509_CreateSelfSigned | Vollständige TsgcX509Options: Subject-DN, Gültigkeitsfenster, Seriennummer, CA-Flag mit Pfadlängenbeschränkung, Key Usage, Extended Key Usage, Subject Alternative Names (einschließlich IPv4-SANs). |
| URI Subject Alternative Names | TsgcX509Options.URIs | uniformResourceIdentifier-SANs, für eine SPIFFE-artige Dienstidentität statt eines Hostnamens. Der Wert wird unverändert als IA5String-Inhalt geschrieben, übergib also eine vollständige URI. |
| PKCS#10-CSR-Erzeugung | sgcX509_CreateCSR | RFC-2986-Certificate-Signing-Request aus demselben Optionen-Record. |
| EC-signierte Zertifikate & CSRs | sgcX509_CreateSelfSignedEx, sgcX509_CreateCSREx, sgcX509_ECKey, sgcX509_RSAKey | Signiere sowohl mit einem EC-Schlüssel als auch mit RSA, indem du einen von beiden in ein TsgcX509SignKey einpackst. Ein EC-Zertifikat ist etwa ein Drittel so groß wie ein RSA-Zertifikat und verifiziert weit schneller. TsgcX509Options.Hash benennt weiterhin nur den SHA, der Algorithmus folgt dem Schlüssel, sodass rhSHA256 mit einem EC-Schlüssel ecdsa-with-SHA256 bedeutet. |
| CA-Ausstellung | sgcX509_CreateSigned, sgcX509_CreateSignedFromCSR | Stelle ein von einem CA-Schlüssel signiertes Zertifikat aus, entweder aus einem Optionen-Record oder aus einem geparsten PKCS#10-Request. |
| Post-Quanten-Signierschlüssel | sgcX509_MLDSAKey, sgcX509_SLHDSAKey | Packe einen ML-DSA- oder SLH-DSA-Schlüssel in ein TsgcX509SignKey und übergib es an sgcX509_CreateSelfSignedEx, sgcX509_CreateCSREx oder die CA-Aussteller. RFC 9881 für ML-DSA, RFC 9909 für SLH-DSA. |
| ML-KEM-Zertifikate | sgcX509_CreateSigned mit einem ML-KEM-Subject-Schlüssel | RFC 9935. Eine CA kann einen ML-KEM-Public-Key zertifizieren, der nicht signieren kann, sodass der Besitz vor der Ausstellung auf anderem Weg nachgewiesen werden muss. |
| Post-Quanten-Schlüsseltypen beim Lesen | TsgcX509PublicKeyType | x509pkMLDSA, x509pkSLHDSA und x509pkMLKEM neben x509pkRSA, x509pkEC und x509pkEd25519. sgcX509_Parse, sgcX509_VerifySignedBy und sgcX509_CSR_Verify verarbeiten sie alle. |
| Kettenbeschränkungen | sgcX509_VerifyChain | Erzwingt die basicConstraints-pathLenConstraint und die nameConstraints-Erweiterung, über dNSName, iPAddress, rfc822Name, uniformResourceIdentifier und directoryName. |
| nameConstraints bei der Erzeugung | TsgcX509Options.PermittedDNSNames, ExcludedDNSNames, PermittedIPRanges, ExcludedIPRanges | Schreibt die erlaubten und die ausgeschlossenen Subtrees in ein CA-Zertifikat, damit der Kettenverifizierer oben sie durchsetzen kann. |
| IPv6-Adress-SANs | TsgcX509Options.IPAddresses | Nimmt IPv6 in jeder Textform nach RFC 4291 an, ebenso IPv4. |
| PEM-Ausgabe | sgcX509_ToPEM | Verpackt den erzeugten DER als speicherfertige PEM-Datei. |
Die drei Algorithmen, die NIST im August 2024 als FIPS 203, 204 und 205 finalisiert hat, plus ein Hybrid-Combiner für die Übergangszeit.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| ML-KEM-Schlüsselerzeugung | sgcMLKEM_GenerateKeyPair, sgcMLKEM_GenerateKeyPairFromSeed | FIPS 203, früher Kyber. Drei Parametersätze: mlkem512, mlkem768, mlkem1024. |
| ML-KEM-Encapsulate | sgcMLKEM_Encapsulate, sgcMLKEM_EncapsulateWithSeed | Erzeugt ein frisches gemeinsames Geheimnis von 32 Byte und den Chiffretext, der es trägt. Der öffentliche Schlüssel durchläuft zuerst die Eingabeprüfungen aus FIPS 203 Abschnitt 7.2, sodass ein Schlüssel falscher Länge oder einer, der die Modulus-Prüfung nicht besteht, eine Ausnahme auslöst. |
| ML-KEM-Decapsulate | sgcMLKEM_Decapsulate | Ein Chiffretext der richtigen Länge, der sich nicht entschlüsseln lässt, liefert ein pseudozufälliges Geheimnis (implizite Zurückweisung) statt eines Fehlers, sodass Timing und Fehlerverhalten nichts preisgeben. Ein Chiffretext oder privater Schlüssel falscher Länge oder ein privater Schlüssel, der die Hash-Prüfung nicht besteht, löst zuerst eine Ausnahme aus, gemäß den Eingabeprüfungen aus FIPS 203 Abschnitt 7.3. |
| ML-KEM-Größen | sgcMLKEM_PublicKeySize, PrivateKeySize, CiphertextSize, SharedSecretSize | Bytelängen pro Parametersatz, zur Pufferdimensionierung. |
| Hybrid X25519 + ML-KEM | sgcHybrid_GenerateKeyPair, sgcHybrid_Encapsulate, sgcHybrid_Decapsulate | Kombiniert ein klassisches und ein Post-Quanten-gemeinsames-Geheimnis über eine KDF, sodass das Ergebnis nie schwächer ist als X25519 allein. Der empfohlene Weg, ML-KEM heute einzusetzen. |
| ML-DSA-Schlüsselerzeugung | sgcMLDSA_GenerateKeyPair, sgcMLDSA_GenerateKeyPairFromSeed | FIPS 204, früher Dilithium. Drei Parametersätze: mldsa44, mldsa65, mldsa87. |
| ML-DSA signieren / verifizieren | sgcMLDSA_Sign / sgcMLDSA_Verify | Deterministisch oder randomisiert signierend gemäß der FIPS-204-Schnittstelle, plus einem Kontext-String. |
| ML-DSA-Größen | sgcMLDSA_PublicKeySize, PrivateKeySize, SignatureSize | Bytelängen pro Parametersatz. |
| SLH-DSA-Schlüsselerzeugung | sgcSLHDSA_GenerateKeyPair, sgcSLHDSA_GenerateKeyPairFromSeed | FIPS 205, früher SPHINCS+. Zustandslose hashbasierte Signaturen: Die Sicherheit ruht allein auf der Hash-Funktion, nicht auf einer Gitter- oder Kurvenannahme. |
| SLH-DSA signieren / verifizieren | sgcSLHDSA_Sign / sgcSLHDSA_Verify | Sechs SHAKE-Parametersätze: slhShake128s, slhShake128f, slhShake192s, slhShake192f, slhShake256s, slhShake256f. Die s-Sätze bevorzugen kleine Signaturen, die f-Sätze bevorzugen schnelles Signieren. |
| SLH-DSA-Größen & Benennung | sgcSLHDSA_PublicKeySize, PrivateKeySize, SignatureSize, sgcSLHDSA_ParamsName | SLH-DSA-Signaturen sind groß (7,8 KB bis 49 KB je nach Satz); den Puffer vor dem Signieren dimensionieren. |
| Public-Key-Export & -Import, DER | sgcMLDSA_ExportSubjectPublicKeyInfo / ImportSubjectPublicKeyInfo sowie die identischen sgcMLKEM_*- und sgcSLHDSA_*-Paare | X.509 SubjectPublicKeyInfo, sodass ein Post-Quanten-Public-Key in dieselbe Struktur geht wie ein RSA- oder EC-Schlüssel. RFC 9881, RFC 9909 und RFC 9935. |
| Export & Import privater Schlüssel, DER | sgcMLDSA_ExportPrivateKeyInfo / ImportPrivateKeyInfo und die Paare sgcMLKEM_* und sgcSLHDSA_* | PKCS#8 OneAsymmetricKey, Versionen 0 und 1. Der Import prüft den Schlüssel auf Konsistenz: Ein eingebetteter öffentlicher Schlüssel, der nicht passt, wird abgelehnt, die Seed- und die expandierte Form desselben Schlüssels müssen übereinstimmen, und ein ML-DSA-Schlüssel muss seine gespeicherten t0 und tr reproduzieren. SLH-DSA berechnet PK.root aus dem Seed neu, was etwa eine Schlüsselerzeugung kostet, daher nehmen diese Importe einen Parameter aVerify entgegen, standardmäßig True, den du für einen von deiner eigenen Anwendung erzeugten Schlüssel als False übergeben kannst. |
| PEM-Export & -Import | sgcMLDSA_ExportPublicKeyPEM, ExportPrivateKeyPEM, ImportPublicKeyPEM, ImportPrivateKeyPEM sowie die sgcMLKEM_*- und sgcSLHDSA_*-Sätze | RFC 7468, der -----BEGIN ... -----END-Wrapper, sodass die Schlüssel in dieselben Dateien und Werkzeuge passen wie der Rest der PKI. |
| Private-Key-Form | TsgcPQCPrivateKeyFormat | ML-DSA- und ML-KEM-Private-Keys haben drei Formen. 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 nur eine einzige Private-Key-Form. |
| Schlüsselerzeugung mit dem Seed | sgcMLDSA_GenerateKeyPairAndSeed, sgcMLKEM_GenerateKeyPairAndSeed | Geben den Seed zusammen mit dem Schlüsselpaar zurück, sodass sich eine PKCS#8- oder PEM-Datei in Seed-Form direkt nach der Erzeugung schreiben lässt. |
| X-Wing-Hybrid-KEM | sgcXWing_GenerateKeyPair, sgcXWing_Encapsulate, sgcXWing_Decapsulate | draft-connolly-cfrg-xwing-kem-10: X25519 mit ML-KEM-768 als ein einziges KEM. Public Key 1216 Byte, Private Key 32 Byte (der Seed), Chiffretext 1120 Byte, Shared Secret 32 Byte. |
| TLS-1.3-Hybrid-Key-Shares | sgcTLSHybrid_ClientKeyShare, sgcTLSHybrid_ServerKeyShare, sgcTLSHybrid_ClientSharedSecret, sgcTLSHybrid_GroupName, sgcTLSHybrid_Available | Die RFC-10024-Gruppen X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 (IANA-Codepoints 0x11EC, 0x11EB, 0x11ED). Das sind keine eigenständigen KEMs, sie bauen nur einen TLS-Key-Share. |
| ML-DSA für JSON Web Tokens | JWTOptions.Algorithms.MLDSA.PrivateKey, PublicKey, Enabled, sgcMLDSA_ExportPublicJWK, sgcMLDSA_ExportPrivateJWK, sgcMLDSA_ImportJWK, sgcMLDSA_ImportJWKAsPEM | RFC 9964, in sgcHTTP_JWT_MLDSA statt in einer sgcCrypto_*-Unit. JWS-Algorithmen ML-DSA-44, ML-DSA-65 und ML-DSA-87 (jwtMLDSA44, jwtMLDSA65, jwtMLDSA87), ein PKCS#8-PEM auf dem Client, ein SubjectPublicKeyInfo-PEM auf dem Server, AKP JSON Web Keys, und kein OpenSSL irgendwo auf diesem Weg. |
| Known-Answer-Validierung | NIST ACVP Vektoren | Die ML-KEM-Schlüsselerzeugung, Encapsulation und Decapsulation sowie die ML-DSA- und SLH-DSA-Schlüsselerzeugung, Signaturerzeugung und Signaturverifikation werden in der QA-Suite von sgcWebSockets gegen die Known-Answer-Vektoren von NIST ACVP geprüft. |
sgcCrypto beansprucht nicht, ed25519187 oder SPECK zu unterstützen. ed25519187 hat keine veröffentlichte Spezifikation, und SPECK wurde 2018 aus der ISO-Standardisierung zurückgezogen; keins von beiden ist hier implementiert.
In Object Pascal auf den sgcCrypto-Primitiven geschrieben und im selben Paket ausgeliefert. Sie liegt in den sgcSSL_NativeTLS*-Units, nicht in sgcCrypto_*, gehört also nicht zu den oben gezählten 43.
| Fähigkeit | API | Hinweise |
|---|---|---|
| An einem Client auswählen | TLSOptions.IOHandler := iohNativeTLS | Ersetzt OpenSSL, SChannel und die Plattform-TLS-Backends durch die In-Process-Pascal-Engine. Auf keinem Ziel gibt es etwas auszuliefern. |
| An einem Server auswählen | SSLOptions.IOHandler := iohNativeTLS | Arbeitet mit der Standard-Indy-Server-Engine sowie mit den IOCP- und EPOLL-Engines. |
| Protokollversion | TLSOptions.Version | Die niedrigste zulässige Version. tls1_2 oder tlsUndefined handelt TLS 1.3 oder TLS 1.2 aus, tls1_3 erlaubt nur TLS 1.3, und tls1_0 oder tls1_1 löst einen Konfigurationsfehler aus. SSLOptions.Version macht dasselbe auf einem Server. Um nur TLS 1.2 zu verwenden, liste in CipherSuites nur TLS-1.2-Suiten auf. |
| Schlüsselaustausch-Gruppen | TLSOptions.NativeTLS_Options.Groups | Durch Doppelpunkte getrennt, im OpenSSL-Stil. Standard X25519MLKEM768:X25519:secp256r1:secp384r1, sodass ein Handshake Post-Quanten-hybrid ist, sobald der Peer zustimmt. Ein Build mit SGC_CRYPTO_FIPS verwendet stattdessen standardmäßig SecP256r1MLKEM768:SecP384r1MLKEM1024:secp256r1:secp384r1. Die drei Hybridgruppen existieren nur in TLS 1.3, sodass eine TLS-1.2-Verbindung X25519, secp256r1 oder secp384r1 verwendet. |
| Cipher-Suites | TLSOptions.NativeTLS_Options.CipherSuites | Durch Doppelpunkte getrennt, im OpenSSL-Stil. Standard TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 für TLS 1.3, dazu ECDHE_ECDSA und ECDHE_RSA mit AES-128-GCM, AES-256-GCM und ChaCha20-Poly1305 für TLS 1.2. ECDHE mit AES-CBC und der RSA-Schlüsselaustausch werden nur verwendet, wenn sie benannt werden, für insgesamt 20 TLS-1.2-Suiten. Ein Build mit SGC_CRYPTO_FIPS lässt ChaCha20-Poly1305 und den RSA-Schlüsselaustausch weg. |
| Vertrauenswürdige Roots | TLSOptions.RootCertFile, TLSOptions.NativeTLS_Options.UseSystemRoots | Die Roots kommen aus RootCertFile. Setze UseSystemRoots auf True, um die Roots hinzuzufügen, denen das Betriebssystem bereits vertraut: den ROOT-Speicher unter Windows, und auf jeder anderen Plattform das erste CA-Bundle, das sich an den Standardorten findet. Dabei wird nie der Schlüsselbund von macOS oder iOS oder der Android-Speicher gelesen. Standardmäßig ist es ausgeschaltet, sodass RootCertFile die Quelle bleibt. Dieselbe Eigenschaft in SSLOptions gilt für die Clientzertifikate, die ein Server verifiziert. |
| Kettenaufbau | die Zertifikatskette, die der Peer sendet | Die Kette wird nach einem Pfad vom Blatt zu einer vertrauenswürdigen Root durchsucht, sodass zusätzliche Zertifikate und jede Reihenfolge akzeptiert werden, wie es RFC 8446 Abschnitt 4.4.2 verlangt. Die Suche verwendet Backtracking, sodass ein Zertifikat, das den richtigen Aussteller nennt, aber ins Leere führt, keinen gültigen Pfad mehr dahinter verbirgt. Widerrufsprüfung und Zertifikatsrichtlinien werden nicht geprüft. |
| Protokollumfang | RFC 8446, RFC 5246 | TLS 1.3 und TLS 1.2. Kein TLS 1.1, TLS 1.0 oder SSL. TLS 1.2 verwendet das Extended Master Secret aus RFC 7627 und den Downgrade-Schutz aus RFC 8446 auf beiden Seiten, verweigert Renegotiation und SHA-1-Signaturen (RFC 9155), und prüft CBC-Datensätze in konstanter Zeit. |
| Nicht implementiert | n/a | Keine Session-Resumption und kein PSK, kein 0-RTT und kein QUIC. |
| Peer-Verifikationsereignis | OnSSLVerifyPeer | Für diese Engine nicht verfügbar, sie hat ihre eigenen Verifikations-Hooks. Bleib bei OpenSSL oder einem Plattform-Backend, wenn dein Code von diesem Ereignis abhängt. |
Die Nutzschicht: Einmalcodes, die Kodierungen, auf die sich jede andere Familie stützt, und WinZip-AES-Verschlüsselung.
| Fähigkeit | Funktion | Hinweise |
|---|---|---|
| HOTP | sgcHOTP | RFC 4226, zählerbasiertes Einmalpasswort. |
| TOTP | sgcTOTP, sgcTOTP_FromBase32 | RFC 6238, zeitbasiertes Einmalpasswort; die Base32-Variante akzeptiert das Secret genau so, wie es eine Authenticator-App anzeigt. |
| TOTP-Verifikation | sgcTOTP_Verify | Prüft einen eingereichten Code über ein Zeitfenster in konstanter Zeit, sodass weder das Ergebnis noch seine Position über Timing durchsickert. Verhindert Replay nicht selbst; der Aufrufer verfolgt bereits genutzte Codes. |
| Konstantzeitiger Vergleich | sgcConstantTimeEquals | Wird in der gesamten Bibliothek für Tag- und MAC-Vergleiche verwendet. |
| Sicheres Nullsetzen | sgcSecureZero | Überschreibt einen Byte-Puffer, damit Schlüsselmaterial nicht im Speicher verweilt. |
| Hex | sgcHexEncode / sgcHexDecode | Kleinbuchstaben-Hex, Groß-/Kleinschreibung wird beim Decodieren ignoriert. |
| Base64url | sgcBase64UrlEncode / sgcBase64UrlDecode | RFC 4648 Abschnitt 5, ungepolstert, die Kodierung, die JWT und JOSE verwenden. |
| Base32 | sgcBase32Encode / sgcBase32Decode | RFC 4648 Abschnitt 6, die Kodierung, die TOTP-Secrets und Authenticator-Apps verwenden. |
| WinZip-AES-Schlüsselableitung | sgcZipAE2_DeriveKeys | PBKDF2-basierter Schlüssel, Authentifizierungsschlüssel und Passwort-Verifier aus einem Passwort und Salt. |
| WinZip-AES verschlüsseln / entschlüsseln | sgcZipAE2_Encrypt / sgcZipAE2_Decrypt | AE-1 und AE-2, AES-128/192/256, Salt-Größe pro Eintrag über TsgcZipAESStrength. |
| WinZip-Eintragspackung | sgcZipAE2_PackEntry / sgcZipAE2_UnpackEntry | Kombiniert Salt, Verifier, Chiffretext und Authentifizierungscode zum Layout auf der Festplatte. |
| WinZip-Extra-Feld | sgcZipAE2_BuildExtraField / sgcZipAE2_ParseExtraField | Das Extra-Feld 0x9901, das einen ZIP-Eintrag als AES-verschlüsselt markiert. |
| Legacy-Hashes (nur Interop) | sgcMD4, sgcMD5, sgcHMAC_MD5 | Erhalten zum Lesen älterer Formate und Protokolle; nicht in einem neuen Design verwenden. |
| Legacy-Chiffre (nur Interop) | sgcDES_EncryptECB / sgcDES_DecryptECB, sgcDES_NTLM7to8 | DES-ECB und der DES-basierte NTLM-Schlüsselerweiterungsschritt, beide zurückgezogen (FIPS 46-3), erhalten für Legacy-Interoperabilität. |
| Sichere Zufallsbytes | sgcRandomBytes / sgcRandomFill | BCryptGenRandom (Windows CNG) unter MSWINDOWS, /dev/urandom anderswo, ein Aufruf für beide Fälle. |
Was unterstützt wird, präzise angegeben.
| Bereich | Detail |
|---|---|
| Betriebssystem | Kein MSWINDOWS-Guard und keine andere Plattformsperre umschließt SGC_CRYPTO in sgcVer.inc. Alle 43 Units kompilieren für Win32, Win64, Linux64, macOS, iOS und Android. |
| Zufallszahlenquelle | Die eine plattformbewusste Unit, sgcCrypto_Random, wählt pro Ziel ein CSPRNG: BCryptGenRandom (Windows CNG) unter MSWINDOWS, /dev/urandom auf POSIX-Zielen, hinter demselben sgcRandomBytes-Aufruf. Die Bytes kommen direkt vom Zufallsgenerator des Betriebssystems, ohne eigenen Generator darüber. Unter Windows werden RtlGenRandom und danach CryptGenRandom nur verwendet, wenn BCryptGenRandom nicht verfügbar ist, und kann keine Quelle gelesen werden, wird eine Exception ausgelöst, statt schwache Bytes zurückzugeben. |
| FIPS-Modus | Optionales Define SGC_CRYPTO_FIPS, standardmäßig deaktiviert, das zur Kompilierzeit jeden nicht zugelassenen Algorithmus aus den 43 Units entfernt und zur Laufzeit einige Parameterregeln prüft. Es beschränkt die Bibliothek auf FIPS-zugelassene Algorithmen, sgcCrypto ist damit aber kein nach FIPS 140-3 validiertes Modul, und das Define ist keine Aussage über eine Validierung. FIPS-Modus |
| Delphi | Delphi 7 bis RAD Studio 13 Florence. Es wird nirgends ein nativer 64-Bit-Integer-Typ vorausgesetzt: sgcCrypto_Int64 und der Typ TsgcBigInt in sgcCrypto_BigInteger emulieren die Arithmetik, die die Hashes, Kurven und Post-Quanten-Units brauchen. |
| C++ Builder | C++ Builder über die generierten Header, derselbe Quellbaum. |
| Design-Time-Footprint | Keiner. Es gibt keine sgcCrypto_Reg.pas, nichts wird per RegisterComponents registriert, und keine Unit erscheint auf einer Palettenseite. |
| Abhängigkeiten | Keine OpenSSL-Anbindung, keine externe DLL. Jede Primitive ist direkt in Object Pascal innerhalb der Unit implementiert, die du referenzierst. |
| Quellcode | Vollständiger Object-Pascal-Quellcode in jeder kostenpflichtigen Stufe, sowie in den Editionspaketen, die sgcCrypto bereits enthalten. |
| Weiterverbreitung | Von dir gebaute Binärdateien sind lizenzgebührenfrei, ohne Pro-Platz- oder Pro-Server-Laufzeitgebühr. |