sgcCrypto — nowoczesna biblioteka kryptograficzna dla Delphi i C++ Builder

sgcCrypto_AES obejmuje CBC, GCM i CTR; sgcCrypto_Modes dodaje ECB, OFB, CFB, ciphertext-stealing CTS, AES-CCM oraz AES Key Wrap / Key Wrap with Padding (RFC 3394 / 5649); sgcCrypto_CMAC to AES-CMAC i AES-GMAC. sgcCrypto_ChaCha implementuje ChaCha20, XChaCha20, Salsa20 i XSalsa20, a sgcCrypto_Poly1305 łączy Poly1305 z nimi w szyfry AEAD ChaCha20-Poly1305 i XChaCha20-Poly1305 z RFC 8439. AES-CCM to szyfr AEAD, który z nazwy wymieniają Zigbee, Bluetooth i zestawy szyfrów CCM w TLS, ponieważ nie potrzebuje niczego poza samym szyfrem blokowym, a CBC i ECB przyjmą dowolny wybrany schemat wypełniania, PKCS#7, ANSI X9.23, ISO 7816-4 i pozostałe, na dzień, gdy trzeba będzie odczytać to, co zapisał inny system. sgcAES_GCM_Decrypt oraz weryfikatory Poly1305 porównują znacznik uwierzytelniający w stałym czasie i odmawiają zwrócenia jawnego tekstu, gdy weryfikacja się nie powiedzie.

sgcCrypto_SHA2 i sgcCrypto_Keccak obejmują SHA-1/2, SHA-3, SHAKE, cSHAKE i KMAC; sgcCrypto_Blake2b i sgcCrypto_Blake2s dodają BLAKE2. sgcCrypto_HMAC to kluczowane uwierzytelnianie wiadomości. Do zamiany hasła na klucz: sgcCrypto_KDF (PBKDF2), sgcCrypto_HKDF, sgcCrypto_Scrypt i sgcCrypto_Argon2, który implementuje wszystkie trzy warianty Argon2 — d, i oraz id — zwycięzcę Password Hashing Competition. sgcCrypto_SipHash daje szybki kluczowany skrót do kluczy tablic mieszających, a sgcCrypto_TLSH to rozmyty skrót z funkcją odległości podobieństwa, nie skrót kryptograficzny, przydatny do wykrywania niemal identycznych plików.

sgcCrypto_Ed25519/Ed448 podpisują i weryfikują; sgcCrypto_X25519/X448 realizują odpowiadający im Diffie-Hellman. sgcCrypto_ECCurves dodaje ECDSA i ECDH nad siedmioma krzywymi, secp256k1, trzema krzywymi Brainpool oraz NIST P-256/P-384/P-521, z deterministycznymi noncami RFC 6979 i podpisami w postaci surowej albo DER, a do tego podpisywanie Schnorra BIP-340, z kluczami publicznymi x-only, jakich oczekują Taproot, Nostr i Lightning. sgcCrypto_EC to bliźniak zorientowany na JOSE: podpisuje i weryfikuje JWS bezpośrednio, ES256/384/512. sgcCrypto_RSA weryfikuje podpisy PKCS#1 v1.5 i PSS wprost z klucza PEM, a sgcCrypto_RSA_Keys idzie dalej, z generowaniem kluczy o dowolnej długości bitowej, szyfrowaniem OAEP i PKCS#1 v1.5 oraz eksportem DER/PEM zarówno w postaci PKCS#1, jak i PKCS#8 BEGIN PRIVATE KEY. Klucze RSA i EC importuje się równie łatwo, jak się je eksportuje, w DER albo PEM, więc raz wygenerowany klucz można zapisać i wczytać ponownie, zamiast żeby żył wyłącznie tak długo, jak proces. sgcCrypto_ECIES dopełnia zestaw hybrydowym szyfrowaniem seal/open do klucza publicznego X25519.

sgcCrypto_ASN1 czyta DER i PEM oraz parsuje klucze PKCS#1/SEC 1; sgcCrypto_DER zapisuje każdy tag potrzebny certyfikatowi lub CSR. sgcCrypto_X509 parsuje certyfikat, weryfikuje, że został podpisany przez danego wystawcę, przechodzi i weryfikuje łańcuch, weryfikuje CSR oraz parsuje CRL, aby sprawdzić unieważnienie. sgcCrypto_X509_Gen generuje od podstaw certyfikat samopodpisany lub żądanie PKCS#10 CSR, a urząd CA wystawia certyfikaty przez sgcX509_CreateSigned albo sgcX509_CreateSignedFromCSR: pełną nazwę wyróżniającą podmiotu i wystawcy, okno ważności, flagę CA z ograniczeniem długości ścieżki, flagi użycia klucza, rozszerzone OID-y użycia klucza oraz alternatywne nazwy podmiotu, wraz z SAN-ami adresów IP, które przyjmują teraz IPv6 w dowolnej postaci tekstowej z RFC 4291, i SAN-ami URI dla tożsamości usług w stylu SPIFFE.

Podpisywanie nie ogranicza się już do RSA i EC. sgcX509_MLDSAKey oraz sgcX509_SLHDSAKey opakowują klucz post-kwantowy dla sgcX509_CreateSelfSignedEx i sgcX509_CreateCSREx, więc certyfikat albo CSR można podpisać kluczem ML-DSA lub SLH-DSA. Urząd CA może również certyfikować klucz publiczny ML-KEM (RFC 9935), który nie potrafi podpisywać, więc posiadanie trzeba udowodnić w inny sposób. Po stronie odczytu TsgcX509PublicKeyType zyskał wartości x509pkMLDSA, x509pkSLHDSA i x509pkMLKEM, a sgcX509_VerifyChain egzekwuje teraz długość ścieżki z basicConstraints oraz rozszerzenie nameConstraints dla dNSName, iPAddress, rfc822Name, uniformResourceIdentifier i directoryName, zapisywane po stronie generowania przez PermittedDNSNames, ExcludedDNSNames, PermittedIPRanges i ExcludedIPRanges. Certyfikat EC nadal wychodzi w przybliżeniu na jedną trzecią rozmiaru certyfikatu RSA i weryfikuje się dużo szybciej, dlatego nowe wdrożenia po niego sięgają.

sgcCrypto_MLKEM to enkapsulacja kluczy z FIPS 203, trzy zestawy parametrów (ML-KEM-512/768/1024), z niejawnym odrzuceniem przy nieprawidłowym szyfrogramie. sgcCrypto_MLDSA to podpisywanie z FIPS 204, ML-DSA-44/65/87. sgcCrypto_SLHDSA to FIPS 205, wszystkie sześć zestawów parametrów SHAKE: 128s, 128f, 192s, 192f, 256s, 256f. Ponieważ samo ML-KEM stawia wszystko na założeniu o kratach młodszym niż krzywe eliptyczne, sgcCrypto_MLKEM_Hybrid łączy sekret X25519 i sekret ML-KEM w jeden klucz współdzielony, więc wynik nigdy nie jest słabszy od klasycznej połowy — to wzorzec migracji, ku któremu zmierza cała branża.

Ta sama jednostka implementuje X-Wing (draft-connolly-cfrg-xwing-kem-10), czyli X25519 razem z ML-KEM-768 jako jeden KEM: klucz publiczny 1216 bajtów, klucz prywatny 32 bajty (ziarno), szyfrogram 1120 bajtów i sekret współdzielony 32 bajty, przez sgcXWing_GenerateKeyPair, sgcXWing_Encapsulate i sgcXWing_Decapsulate. Buduje też hybrydowe udziały klucza TLS 1.3 z RFC 10024 dla X25519MLKEM768, SecP256r1MLKEM768 i SecP384r1MLKEM1024 (punkty kodowe IANA 0x11EC, 0x11EB i 0x11ED). Te trzy nie są samodzielnymi mechanizmami KEM, budują wyłącznie udział klucza TLS.

Wszystkie trzy algorytmy odczytują i zapisują teraz klucze jako X.509 SubjectPublicKeyInfo, PKCS#8 OneAsymmetricKey oraz PEM, więc klucz post-kwantowy mieszka w tych samych plikach co klucz RSA czy EC. Klucze prywatne ML-DSA i ML-KEM mają trzy postaci, wybierane przez TsgcPQCPrivateKeyFormat: pqkfSeed zapisuje samo ziarno (32 bajty dla ML-DSA, 64-bajtowe ziarno d||z dla ML-KEM), pqkfExpanded zapisuje klucz rozwinięty, a pqkfBoth niesie obie postaci. SLH-DSA ma tylko jedną postać klucza prywatnego. sgcMLDSA_GenerateKeyPairAndSeed i sgcMLKEM_GenerateKeyPairAndSeed zwracają ziarno obok pary kluczy, więc plik w postaci ziarna można zapisać zaraz po wygenerowaniu.

sgcCrypto_OTP generuje i weryfikuje kody HOTP i TOTP, te same sześciocyfrowe kody, które pokazuje aplikacja uwierzytelniająca, z oknem weryfikacji w stałym czasie, które pochłania przesunięcie zegara. sgcCrypto_Encoding zawiera funkcje narzędziowe współdzielone przez resztę biblioteki: porównanie w stałym czasie, bezpieczne zerowanie bufora, hex, Base64url i Base32. sgcCrypto_Zip_AE2 implementuje szyfrowanie WinZip AES, AE-1 i AE-2, do szyfrowania pojedynczych wpisów ZIP. sgcCrypto_Random to wieloplatformowy CSPRNG stojący za każdym kluczem i noncem generowanym gdzie indziej w bibliotece, a sgcCrypto_Legacy utrzymuje MD4/MD5/HMAC-MD5/DES-ECB dostępne dla współpracy ze starszymi formatami, nie do nowych projektów.