sgcCrypto 功能矩阵

sgcCrypto 所做的一切，映射到磁盘上的 43 个单元。这里没有组件，也没有设计时属性：下面的每一行都是一个可以直接调用的函数或过程。每份许可证都附带完整源代码。下方的锚点会带您跳转到这些单元所属的六大能力分类，以及同一个产品包在它们之上构建的 TLS 1.3 和 TLS 1.2 引擎。

sgcCrypto 没有组件。下面的 43 个单元只导出普通函数，没有 Tsgc* 类，也没有 sgcCrypto_Reg.pas。将一个单元添加到您的 uses 子句中，然后调用该函数即可。

已经包含在内。sgcCrypto 已免费包含在 sgcWebSockets Standard、Professional 和 Enterprise 中，以及 All-Access 中。它也作为独立产品出售（捆绑 sgcWebSockets Core 运行时），供只拥有 Core 的客户使用。参见价格页面。

对称加密

AES、CCM、ChaCha20、Poly1305，5 个单元

哈希与 KDF

SHA-2/3、BLAKE2、Argon2，11 个单元

签名与密钥交换

Ed25519、X25519、Schnorr、RSA，10 个单元

PKI

X.509、ASN.1、RSA 和 EC CSR，5 个单元

后量子

ML-KEM、ML-DSA、SLH-DSA，6 个单元

OTP 与杂项

HOTP/TOTP、编码、ZIP AES，6 个单元

TLS 1.3 和 1.2 引擎

iohNativeTLS、X25519MLKEM768，纯 Pascal

单元

43 个源码单元

sgcWebSockets/delphi/Source/ 下的每个 sgcCrypto_*.pas 单元，按分类列出。

单元分类功能
sgcCrypto_AES对称加密AES-CBC、AES-GCM（AEAD）、AES-CTR。
sgcCrypto_Modes对称加密AES-ECB、OFB、CFB、CTS、CCM（AEAD）、Key Wrap / 带填充的 Key Wrap，以及七种填充方案。
sgcCrypto_CMAC对称加密AES-CMAC 和 AES-GMAC 消息认证。
sgcCrypto_ChaCha对称加密ChaCha20、XChaCha20、Salsa20、XSalsa20。
sgcCrypto_Poly1305对称加密Poly1305 MAC、ChaCha20-Poly1305 和 XChaCha20-Poly1305 AEAD。
sgcCrypto_SHA2哈希与 KDFSHA-1、SHA-224、SHA-256、SHA-384、SHA-512。
sgcCrypto_Keccak哈希与 KDFSHA-3、SHAKE128/256、cSHAKE、KMAC。
sgcCrypto_Blake2b哈希与 KDFBLAKE2b，带密钥或不带密钥。
sgcCrypto_Blake2s哈希与 KDFBLAKE2s，带密钥或不带密钥。
sgcCrypto_HMAC哈希与 KDFHMAC-SHA1/256/384/512。
sgcCrypto_KDF哈希与 KDFPBKDF2、KDF1、KDF2 和 X9.63，可选哈希算法。
sgcCrypto_HKDF哈希与 KDFHKDF 提取与展开。
sgcCrypto_Scrypt哈希与 KDFscrypt 内存困难型 KDF。
sgcCrypto_Argon2哈希与 KDFArgon2d、Argon2i、Argon2id。
sgcCrypto_SipHash哈希与 KDFSipHash-2-4 带密钥哈希。
sgcCrypto_TLSH哈希与 KDFTLSH 模糊哈希与相似度比较。
sgcCrypto_Ed25519签名与密钥交换Ed25519 签名 / 验证。
sgcCrypto_X25519签名与密钥交换X25519 Diffie-Hellman。
sgcCrypto_Ed448签名与密钥交换Ed448 签名 / 验证。
sgcCrypto_X448签名与密钥交换X448 Diffie-Hellman。
sgcCrypto_GF448签名与密钥交换为 Ed448/X448 提供内部 GF(2^448-2^224-1) 域运算。
sgcCrypto_ECCurves签名与密钥交换基于 secp256k1、Brainpool P256r1/P384r1/P512r1 和 NIST P-256/P-384/P-521 的 ECDSA / ECDH，DER 签名，密钥导出/导入，以及 BIP-340 Schnorr。
sgcCrypto_EC签名与密钥交换通用 EC 签名/验证，格式为 JWS（ES256/384/512），以及 ECDH。
sgcCrypto_RSA签名与密钥交换RSA PKCS#1 v1.5 签名，PKCS#1 v1.5 / PSS 验证，来自 PEM 或原始数据。
sgcCrypto_RSA_Keys签名与密钥交换RSA 密钥生成、OAEP（可独立指定 MGF1 哈希）、PSS、PKCS#1 v1.5 签名/验证/加密/解密、PKCS#1 和 PKCS#8 格式的 DER/PEM 导出与导入。
sgcCrypto_ECIES签名与密钥交换基于 X25519 的 ECIES 封装 / 解封混合加密。
sgcCrypto_ASN1PKIDER 读取器、PEM 编解码器、PKCS#1/SEC 1 密钥解析。
sgcCrypto_DERPKIDER 写入原语。
sgcCrypto_BigIntegerPKI内部任意精度整数运算。
sgcCrypto_X509PKIX.509 解析、验证、带 pathLenConstraint 与 nameConstraints 的证书链验证、CSR 验证、CRL、吊销检查。可读取 RSA、EC、Ed25519、ML-DSA、SLH-DSA 和 ML-KEM 公钥。
sgcCrypto_X509_GenPKI自签名、CA 签发和 PKCS#10 CSR 生成，可使用 RSA、EC、ML-DSA 或 SLH-DSA 签名，并支持 URI 与 IPv6 主题备用名称以及 nameConstraints。
sgcCrypto_MLKEM后量子ML-KEM 密钥封装（FIPS 203），3 种参数集，支持 SubjectPublicKeyInfo、PKCS#8 和 PEM 密钥导入导出。
sgcCrypto_MLKEM_Poly后量子ML-KEM 背后的内部多项式环运算。
sgcCrypto_MLKEM_Hybrid后量子混合 X25519 + ML-KEM 密钥封装、X-Wing，以及 RFC 10024 的 TLS 1.3 混合密钥共享。
sgcCrypto_MLDSA后量子ML-DSA 数字签名（FIPS 204），3 种参数集，支持 SubjectPublicKeyInfo、PKCS#8 和 PEM 密钥导入导出。
sgcCrypto_MLDSA_Poly后量子ML-DSA 背后的内部多项式环运算。
sgcCrypto_SLHDSA后量子SLH-DSA 签名（FIPS 205），6 种 SHAKE 参数集，支持 SubjectPublicKeyInfo、PKCS#8 和 PEM 密钥导入导出。
sgcCrypto_OTPOTP 与杂项HOTP、TOTP，恒定时间验证窗口。
sgcCrypto_EncodingOTP 与杂项恒定时间比较、安全清零、十六进制/Base64url/Base32。
sgcCrypto_Zip_AE2OTP 与杂项ZIP 条目的 WinZip AES 加密，AE-1 / AE-2。
sgcCrypto_LegacyOTP 与杂项MD4、MD5、HMAC-MD5、DES-ECB、RIPEMD-160 和 HMAC-RIPEMD160，仅用于互操作。
sgcCrypto_RandomOTP 与杂项跨平台 CSPRNG。
sgcCrypto_Int64OTP 与杂项为 Delphi 7 提供的内部 64 位整数模拟。
对称加密

加密与 MAC

生产代码实际会用到的 AES 模式，外加 ChaCha20/Poly1305 AEAD 系列。

能力函数说明
AES-CBCsgcAES_CBC_Encrypt / sgcAES_CBC_DecryptPKCS#7 填充，16 字节 IV。密钥长度决定所用的密码：16/24/32 字节对应 AES-128/192/256。
无填充的 AES-CBCsgcAES_CBC_Encrypt_NoPad / sgcAES_CBC_Decrypt_NoPadJava 写作 AES/CBC/NoPadding 的模式。输入长度必须已经是 16 字节的整数倍；长度不对齐时会引发异常，而不是被悄悄填充成对方无法读取的内容。
AES-GCM（AEAD）sgcAES_GCM_Encrypt / sgcAES_GCM_Decrypt建议使用 12 字节 IV。16 字节标签，以恒定时间比较；标签校验失败时解密函数返回 False 和空明文。
AES 内核sgcAES_GetCore / sgcAES_SetCoreaescConstantTime 为默认值，是一个位切片内核，从不用机密字节索引内存，也从不依据它分支，从而堵住了针对密钥和明文的缓存时序通道。aescTable 是经典的查表内核，会通过数据缓存泄露信息，并且在每次测量中都更慢，因此仅作为后备保留。用于认证 GCM 的 GHASH 在掩码下相乘，而不是依据密钥分支。请在启动时设置一次内核，且要在任何工作线程运行之前。
AES-CCM（AEAD）sgcAES_CCM_Encrypt / sgcAES_CCM_Decrypt资源受限设备和物联网协议栈所指定使用的 AEAD：Zigbee、802.15.4、蓝牙以及 TLS CCM 密码套件，因为它只需要分组密码本身，无需 GHASH 表。随机数为 7 到 13 字节，标签为 4 到 16 字节，以恒定时间验证。
AES-CTRsgcAES_CTRSRTP 风格的 AES-CM（RFC 3711）。对称调用，无填充，128 位大端计数器。
AES-ECBsgcAES_ECB_Encrypt / sgcAES_ECB_Decrypt没有 IV，没有链接。为了与指定该模式的格式互操作而提供。
填充方案sgcPad_Add / sgcPad_Remove、sgcAES_CBC_EncryptPad / DecryptPad、sgcAES_ECB_EncryptPad / DecryptPadTsgcPadding 涵盖 None、PKCS#7、Zero、ANSI X9.23、ISO 7816-4、ISO 10126-2 和 TBC，因此 CBC 和 ECB 都能读写并非选择 PKCS#7 的系统所生成的数据。sgcPad_Remove 对任何一种错误填充都走同一条路径，返回 False。
AES-OFB / AES-CFBsgcAES_OFB、sgcAES_CFB_Encrypt / sgcAES_CFB_Decrypt流密码风格的反馈模式。
AES-CTSsgcAES_CTS_Encrypt / sgcAES_CTS_Decrypt密文窃取：加密长度不是块大小整数倍的数据，且无需填充开销。
AES Key WrapsgcAES_KeyWrap / sgcAES_KeyUnwrapRFC 3394，用于将一个密钥包装在另一个密钥之下。
带填充的 AES Key WrapsgcAES_KeyWrapPad / sgcAES_KeyUnwrapPadRFC 5649，用于长度不是 8 字节整数倍的密钥材料。
AES-CMACsgcAES_CMAC / sgcAES_CMAC_VerifyRFC 4493 消息认证码。
AES-GMACsgcAES_GMAC / sgcAES_GMAC_VerifyGCM 的仅认证模式：整条消息都作为附加数据传输，没有任何内容被加密。同一个密钥下 IV 绝不能重复，16 字节标签以恒定时间比较。
底层块原语sgcAES_ExpandKey、sgcAES_EncryptBlock、sgcAES_DecryptBlock供上述模式和 MAC 单元使用；仅在需要构建一种尚未提供的模式时才直接调用。
ChaCha20sgcChaCha20RFC 8439，96 位 nonce，32 位计数器。
XChaCha20sgcXChaCha20192 位扩展 nonce，适合大规模生成随机 nonce 的场景。
Salsa20 / XSalsa20sgcSalsa20 / sgcXSalsa20前身流密码系列，两种 nonce 长度均支持。
子密钥派生sgcHChaCha20 / sgcHSalsa20X 变体内部用它们从前 16 个 nonce 字节派生子密钥。
Poly1305 MACsgcPoly1305 / sgcPoly1305_Verify一次性认证器，RFC 8439。切勿重复使用同一个 Poly1305 密钥。
ChaCha20-Poly1305 AEADsgcChaCha20Poly1305_Encrypt / _DecryptTLS 1.3 第二套密码套件以及 SSH 背后所用的 AEAD 密码。
XChaCha20-Poly1305 AEADsgcXChaCha20Poly1305_Encrypt / _Decrypt同样的 AEAD，192 位 nonce，即 libsodium 所称的 crypto_aead_xchacha20poly1305_ietf 构造。
哈希与密钥派生

摘要、MAC 与密码哈希

每一种主流哈希系列，外加 PBKDF2、HKDF、scrypt 以及全部三种 Argon2 变体。

能力函数说明
SHA-1 / SHA-2sgcSHA1、sgcSHA224、sgcSHA256、sgcSHA384、sgcSHA512FIPS 180-4。SHA-1 仅为互操作而保留，不建议用于新签名。
SHA-3sgcSHA3_224 / _256 / _384 / _512FIPS 202，Keccak 海绵结构，与 SHA-2 在结构上完全独立。
SHAKE128 / SHAKE256sgcSHAKE128 / sgcSHAKE256可扩展输出函数：可请求任意摘要长度。
cSHAKE128 / cSHAKE256sgcCSHAKE128 / sgcCSHAKE256带域分离的 SHAKE，NIST SP 800-185，是 KMAC 的基础。
KMAC128 / KMAC256sgcKMAC128 / sgcKMAC256基于 Keccak 的 MAC，输出长度可变。
BLAKE2bsgcBlake2b / sgcBlake2b_KeyedRFC 7693，摘要长度最多 64 字节，内置密钥支持（无需单独的 HMAC）。
BLAKE2ssgcBlake2s / sgcBlake2s_KeyedRFC 7693，摘要长度最多 32 字节，为 32 位平台优化。
流式摘要sgcBlake2b_Init/_Update/_Final，Keccak/Blake2s 上的对应调用用于哈希无法一次性放入内存的大型数据。
HMACsgcHMAC_SHA1 / _SHA256 / _SHA384 / _SHA512RFC 2104，基于 SHA-1/2 系列的带密钥哈希。
RIPEMD-160 / HMAC-RIPEMD160sgcRIPEMD160、sgcHMAC_RIPEMD160ISO/IEC 10118-3 与 RFC 2286。比特币地址叠加在 SHA-256 之上使用的 160 位摘要，也是 OpenPGP 按名称指定使用的哈希。
PBKDF2sgcPBKDF2、sgcPBKDF2_SHA1 / _SHA256 / _SHA512RFC 8018。仅具备轻度内存困难性；可选时优先使用 Argon2id 或 scrypt。
HKDFsgcHKDF_Extract_SHA256 / _SHA384、sgcHKDF_Expand_SHA256 / _SHA384、sgcHKDF_SHA256 / _SHA384RFC 5869，提取再展开的密钥派生方式，是将共享密钥转换为多个密钥的标准做法。
KDF1 / KDF2 / X9.63sgcKDF1、sgcKDF2、sgcKDF_X963ISO 18033-2、IEEE 1363a 和 ANSI X9.63 定义的计数器模式密钥派生函数，也是 RSA-KEM 和 ECIES 按名称指定使用的函数。KDF1 从 0 开始计数，KDF2 从 1 开始，这一差异已经造成过真实的互操作性问题，请务必核实您的规范所指的是哪一个。
scryptsgcScryptRFC 7914，内存困难，抵御 GPU/ASIC 攻击的能力远优于 PBKDF2。
Argon2sgcArgon2（d / i / id）、便捷封装 sgcArgon2idRFC 9106，密码哈希竞赛的获胜者。完整接口支持可选密钥（pepper）和关联数据。
SipHash-2-4sgcSipHash24 / sgcSipHash24_Value用于哈希表键的快速带密钥 PRF，可抵御哈希洪泛拒绝服务。
TLSH 模糊哈希sgcTLSH、sgcTLSH_Init/_Update/_Final用于近似重复检测的局部敏感哈希，不是密码学摘要。
TLSH 相似度分数sgcTLSH_Diff两个 TLSH 摘要之间的距离；数值越低表示越相似。
签名与密钥交换

Ed25519/Ed448、X25519/X448、secp256k1、Brainpool 和 RSA

在五个不同的曲线系列以及 RSA 上进行签名、验证和共享密钥推导。

能力函数说明
Ed25519 签名 / 验证sgcEd25519_Sign / sgcEd25519_Verify、sgcEd25519_PublicKeyRFC 8032。32 字节公钥，64 字节签名。验证会拒绝非规范点以及第 5.1.7 节所规定的 S >= L 情形。签名对机密标量和每条消息的 nonce 都是恒定时间的：固定的四位窗口，通过在掩码下扫描全部十六个条目来选取表项，以及第 5.1.4 节的完备加法公式。公钥由 32 字节种子生成。
X25519 密钥交换sgcX25519、sgcX25519_PublicKey、sgcX25519_SharedSecretRFC 7748，基于 Curve25519 的 Diffie-Hellman。
Ed448 签名 / 验证sgcEd448_GenerateKeyPair、sgcEd448_Sign、sgcEd448_VerifyRFC 8032，448 位（Goldilocks）EdDSA 曲线。
X448 密钥交换sgcX448、sgcX448_PublicKey、sgcX448_SharedSecretRFC 7748，基于 Curve448 的 Diffie-Hellman。
secp256k1使用 eccSecp256k1 的 sgcECDSA_SignHash / VerifyHash比特币/以太坊所用的曲线，SEC 2，位于 sgcCrypto_ECCurves 中。
Brainpool P256r1 / P384r1 / P512r1同一组函数，配合 eccBrainpoolP256r1 / P384r1 / P512r1RFC 5639，常见于欧盟 eIDAS 和政府配置文件。
NIST P-256 / P-384 / P-521同一组函数，配合 eccP256 / eccP384 / eccP521TsgcECCurve 现在命名了七条曲线，因此密钥生成、签名、验证、ECDH 和点压缩都能直接从原始密钥字节到达 NIST 素数曲线，而不必再借助 PEM 文件。
确定性 ECDSA nonce内置于 sgcECDSA_SignHashRFC 6979：nonce 由私钥和消息派生，没有 RNG 失效的风险。
恒定时间标量乘法位于 sgcECDSA_SignHash、sgcECDH_SharedSecret 和 EC 密钥生成内部sgcCrypto_ECCurves 中的每条曲线都运行同一个引擎：没有数据相关步骤的 Montgomery 约简，窗口数量由曲线决定的固定窗口，在掩码下扫描全部条目来选取表项，以及从不查看坐标来判断适用哪种情况的完备加法公式。sgcCrypto_EC 的 JOSE、WebAuthn 和 E2EE 路径运行同一份代码。
ECDH（secp256k1 / Brainpool）sgcECDH_SharedSecret在同一四条曲线上计算共享密钥。
点压缩sgcEC_Compress / sgcEC_Decompress存储或传输更短的压缩公钥形式。
EC 作为 JWS（ES256/384/512）sgcECDSA_SignJWS / sgcECDSA_VerifyJWS根据所请求的位长自动选择曲线，可直接从 PEM 密钥签名/验证，是 ECCurves 面向 JOSE 的姊妹单元。
通用 ECDHsgcECDH由原始私钥和对方公钥点计算共享密钥。
原始 / DER ECDSA 验证sgcECDSA_VerifyRaw / sgcECDSA_VerifyDER针对原始 (Qx, Qy, r, s) 元组或 DER 编码签名进行验证。
DER ECDSA 签名与格式互转sgcECDSA_SignDER / sgcECDSA_VerifyDER、sgcECDSA_RawToDER / sgcECDSA_DERToRawX.509、CMS 和 TLS 携带的是 DER 编码的 ECDSA-Sig-Value，即先 INTEGER r 后 INTEGER s 的 SEQUENCE。JOSE 和 WebAuthn 携带的则是原始的 R || S 字节对。既可以直接签出任意一种形式，也可以在两者之间转换一个已有的签名。
Schnorr 签名（BIP-340）sgcSchnorr_PublicKey、sgcSchnorr_Sign、sgcSchnorr_Verify仅限 secp256k1，采用仅 x 坐标的 32 字节公钥和 64 字节签名：Taproot、Nostr 和 Lightning 所使用的正是它。sgcSchnorr_TaggedHash 被单独导出，以便在同一构造之上构建 BIP-341 和 BIP-342 所需的标签。
RSA 签名（PKCS#1 v1.5）sgcRSA_SignPKCS1从 PEM 私钥出发，SHA-1/256/384/512 摘要。
RSA 私钥操作sgcRSA_SignPKCS1 以及 sgcCrypto_RSA_Keys 中其他的签名和解密调用每次操作都用新的随机数对进行盲化，再经过固定窗口幂运算和 CRT 重组，其耗时不取决于因子或数据，并且在返回结果之前会用公钥指数进行检查。CRT 某一半中的错误否则会在一次签名中泄露一个因子，因此一旦不匹配就不返回任何结果。
RSA 验证（PKCS#1 v1.5 / PSS）sgcRSA_VerifyPKCS1、sgcRSA_VerifyPSS，以及基于模数/指数的 _Raw 变体RFC 8017。验证既可来自 PEM 密钥，也可来自原始模数和指数，无需构建密钥对象。
RSA 密钥生成sgcRSA_GenerateKey任意请求的位长，Miller-Rabin 素性测试。
RSA-OAEP 加密sgcRSA_OAEP_Encrypt / sgcRSA_OAEP_DecryptRFC 8017 最优非对称加密填充。
带独立 MGF1 哈希的 RSA-OAEP五参数版本的 sgcRSA_OAEP_Encrypt / sgcRSA_OAEP_Decrypt 重载分别锁定标签哈希和 MGF1 哈希。OAEPWithSHA256AndMGF1Padding 在 Bouncy Castle 中意味着两者都是 SHA-256，而在 SunJCE 中却是 SHA-256 配合 MGF1-SHA1，这一不一致正是 Java 互操作性失败的常见原因。
RSA PKCS#1 v1.5 加密sgcRSA_PKCS1_Encrypt / sgcRSA_PKCS1_DecryptRFC 8017 第 7.2 节，Java 中称为 RSA/ECB/PKCS1Padding 的模式。解密对任何一种失败都走同一条路径，因此不会给填充预言攻击留下任何可乘之机。任何新场景都应优先选择 OAEP。
RSA-PSS / PKCS#1 签名sgcRSA_PSS_Sign / Verify、sgcRSA_PKCS1_Sign / Verify直接从生成的 TsgcRSAPrivateKey 进行签名。
RSA 密钥导出sgcRSA_ExportPrivateKeyPEM、sgcRSA_ExportPublicKeyPEM，以及对应的 DER 调用PKCS#1 和 SubjectPublicKeyInfo 编码。
PKCS#8 与 SEC 1 密钥导出sgcRSA_ExportPrivateKeyPKCS8DER / PKCS8PEM、sgcEC_ExportPrivateKeyPKCS8DER / PKCS8PEM、sgcEC_ExportPrivateKeySEC1DER / SEC1PEM、sgcEC_ExportSubjectPublicKeyInfo、sgcEC_ExportPublicKeyPEMJava、.NET 及大多数现代工具所期望的 BEGIN PRIVATE KEY 容器，以及 SEC 1 的 BEGIN EC PRIVATE KEY 形式，还有证书内嵌的 SubjectPublicKeyInfo。三者均未加密，因此返回的是裸密钥材料。
RSA 与 EC 密钥导入sgcRSA_ImportPrivateKeyDER / PEM、sgcRSA_ImportPublicKeyDER / PEM、sgcEC_ImportPrivateKeyDER / PEM、sgcEC_ImportPublicKeyDER / PEM此前并不存在：生成的密钥只能写出，却无法再读回来。导入功能接受 PKCS#1、PKCS#8、SEC 1 和 SubjectPublicKeyInfo，DER 或 PEM 格式均可，文件缺省 CRT 参数或公钥点时会重新计算，遇到格式错误的输入会返回 False 而不是抛出异常，因此可以放心地用它处理不受信任的文件。
ECIES 封装 / 解封sgcECIES_GenerateKeyPair、sgcECIES_Seal、sgcECIES_Open面向 X25519 公钥的混合加密：临时 ECDH 加上一个 AEAD，每个方向仅需一次调用。
PKI

X.509 证书与 ASN.1

读取他人签发的证书，或自己生成一份，两者底层都有同一套 DER 编码器和解码器。

能力函数说明
DER 读取器sgcASN1_Read、sgcASN1_Next、sgcASN1_Content逐个节点遍历 DER 结构。
严格 DERsgcASN1_Read、sgcASN1_IsMinimalUnsignedInteger该单元读取的每一种结构按规范都是 DER，因此长度受 DER 规则约束：不定长形式会被拒绝，本可以用短形式承载的长形式同样会被拒绝。INTEGER 没有采用最小编码的 ECDSA 签名也会被拒绝，因此同一个签名不可能有两种写法而被当作两个不同的值。
PEM 编解码器sgcPEM_Decode / sgcPEM_EncodeRFC 7468，包裹 DER 的 -----BEGIN ... -----END 格式。
RSA 密钥解析sgcASN1_ParseRSAPrivateKey / PublicKeyPKCS#1（RFC 8017）密钥结构。
EC 密钥解析sgcASN1_ParseECPrivateKey / PublicKeySEC 1 密钥结构。
结构性 DER 写入sgcDER_Sequence、sgcDER_Set、sgcDER_Tagged、sgcDER_ContextExplicit / Implicit每个证书字段所依赖的基础构件。
数值型 DER 写入sgcDER_Integer、sgcDER_OctetString、sgcDER_BitString、sgcDER_Boolean、sgcDER_Null基本值编码器。
字符串与标识符 DER 写入sgcDER_OID、sgcDER_UTF8String、sgcDER_PrintableString、sgcDER_IA5String、sgcDER_Time对象标识符、X.509 使用的三种字符串类型，以及 UTCTime/GeneralizedTime。
证书解析sgcX509_Parse完整的证书结构：主题、颁发者、有效期、公钥、扩展项。
签名 / 证书链验证sgcX509_VerifySignedBy、sgcX509_VerifyChain验证一张证书是否由某个颁发者签发，或者遍历并验证一组 DER 证书。
CRL 解析与吊销检查sgcX509_CRL_Parse、sgcX509_IsRevoked、sgcX509_CRL_VerifySignedBy解析证书吊销列表，并对照它检查某个序列号。
名称格式化sgcX509_SubjectRFC2253、sgcX509_IssuerRFC2253、sgcX509_SubjectOneLineRFC 2253 可分辨名称字符串，用于日志记录和显示。
扩展项与 SANsgcX509_GetExtension、sgcX509_GetCRLDistributionURIs读取任意扩展 OID 以及 CRL 分发点 URI。
自签名证书生成sgcX509_CreateSelfSigned完整的 TsgcX509Options：主题 DN、有效期、序列号、带路径长度限制的 CA 标志、密钥用途、扩展密钥用途、主题备用名称（包括 IPv4 SAN）。
URI 主题备用名称TsgcX509Options.URIsuniformResourceIdentifier 类型的 SAN，用于表示 SPIFFE 风格的服务身份，而非主机名。该值会按原样作为 IA5String 内容写入，因此请传入完整的 URI。
PKCS#10 CSR 生成sgcX509_CreateCSR基于同一个选项记录生成 RFC 2986 证书签名请求。
EC 签名的证书与 CSRsgcX509_CreateSelfSignedEx、sgcX509_CreateCSREx、sgcX509_ECKey、sgcX509_RSAKey将 RSA 或 EC 密钥封装进一个 TsgcX509SignKey，即可同时支持这两种密钥进行签名。EC 证书体积大约只有 RSA 证书的三分之一，验证速度也快得多。TsgcX509Options.Hash 仍然只指定 SHA 算法，签名算法则由密钥类型决定，因此 rhSHA256 配合 EC 密钥意味着 ecdsa-with-SHA256。
CA 签发sgcX509_CreateSigned、sgcX509_CreateSignedFromCSR用 CA 密钥签发证书，既可以从选项记录出发，也可以从解析后的 PKCS#10 请求出发。
后量子签名密钥sgcX509_MLDSAKey、sgcX509_SLHDSAKey把 ML-DSA 或 SLH-DSA 密钥包装进 TsgcX509SignKey，再交给 sgcX509_CreateSelfSignedEx、sgcX509_CreateCSREx 或上面的 CA 签发函数。ML-DSA 对应 RFC 9881，SLH-DSA 对应 RFC 9909。
ML-KEM 证书带 ML-KEM 主题密钥的 sgcX509_CreateSignedRFC 9935。CA 可以为 ML-KEM 公钥签发证书，但 ML-KEM 无法签名，所以签发前必须用其他方式证明私钥持有。
读取时的后量子密钥类型TsgcX509PublicKeyType在 x509pkRSA、x509pkEC 和 x509pkEd25519 之外新增 x509pkMLDSA、x509pkSLHDSA 和 x509pkMLKEM。sgcX509_Parse、sgcX509_VerifySignedBy 和 sgcX509_CSR_Verify 都能处理它们。
证书链约束sgcX509_VerifyChain强制执行 basicConstraints 的 pathLenConstraint 以及 nameConstraints 扩展，覆盖 dNSName、iPAddress、rfc822Name、uniformResourceIdentifier 和 directoryName。
生成时写入 nameConstraintsTsgcX509Options.PermittedDNSNames、ExcludedDNSNames、PermittedIPRanges、ExcludedIPRanges把允许和排除的子树写入 CA 证书，上面的链验证才能强制执行它们。
IPv6 地址 SANTsgcX509Options.IPAddresses接受任意 RFC 4291 文本形式的 IPv6，也接受 IPv4。
PEM 输出sgcX509_ToPEM将生成的 DER 包装为可直接保存的 PEM 文件。
后量子

ML-KEM、ML-DSA 和 SLH-DSA

NIST 于 2024 年 8 月定稿为 FIPS 203、204 和 205 的三种算法，外加为过渡期提供的一个混合组合器。

能力函数说明
ML-KEM 密钥生成sgcMLKEM_GenerateKeyPair、sgcMLKEM_GenerateKeyPairFromSeedFIPS 203，原名 Kyber。三种参数集：mlkem512、mlkem768、mlkem1024。
ML-KEM 封装sgcMLKEM_Encapsulate、sgcMLKEM_EncapsulateWithSeed生成一个新的 32 字节共享密钥，以及承载它的密文。公钥会先经过 FIPS 203 第 7.2 节的输入检查，因此长度不对或未通过模数检查的公钥会引发异常。
ML-KEM 解封装sgcMLKEM_Decapsulate长度正确但无法解密的密文会得到一个伪随机密钥（隐式拒绝），而不是错误，因此时序和错误行为都不会泄露任何信息。长度不对的密文或私钥，或者未通过哈希检查的私钥，会依据 FIPS 203 第 7.3 节的输入检查首先引发异常。
ML-KEM 尺寸sgcMLKEM_PublicKeySize、PrivateKeySize、CiphertextSize、SharedSecretSize每种参数集对应的字节长度，用于缓冲区分配。
混合 X25519 + ML-KEMsgcHybrid_GenerateKeyPair、sgcHybrid_Encapsulate、sgcHybrid_Decapsulate通过一个 KDF 将经典和后量子共享密钥组合起来，因此结果的安全性永远不会弱于单独的 X25519。这是当前业界推荐的 ML-KEM 部署方式。
ML-DSA 密钥生成sgcMLDSA_GenerateKeyPair、sgcMLDSA_GenerateKeyPairFromSeedFIPS 204，原名 Dilithium。三种参数集：mldsa44、mldsa65、mldsa87。
ML-DSA 签名 / 验证sgcMLDSA_Sign / sgcMLDSA_Verify按照 FIPS 204 接口进行确定性或随机化签名，并支持上下文字符串。
ML-DSA 尺寸sgcMLDSA_PublicKeySize、PrivateKeySize、SignatureSize每种参数集对应的字节长度。
SLH-DSA 密钥生成sgcSLHDSA_GenerateKeyPair、sgcSLHDSA_GenerateKeyPairFromSeedFIPS 205，原名 SPHINCS+。无状态哈希签名：安全性完全依赖哈希函数本身，不依赖格或曲线假设。
SLH-DSA 签名 / 验证sgcSLHDSA_Sign / sgcSLHDSA_Verify六种 SHAKE 参数集：slhShake128s、slhShake128f、slhShake192s、slhShake192f、slhShake256s、slhShake256f。s 系列偏向更小的签名，f 系列偏向更快的签名速度。
SLH-DSA 尺寸与命名sgcSLHDSA_PublicKeySize、PrivateKeySize、SignatureSize、sgcSLHDSA_ParamsNameSLH-DSA 签名体积较大（根据参数集不同，从 7.8 KB 到 49 KB 不等）；签名前请先确定缓冲区大小。
公钥导出与导入，DERsgcMLDSA_ExportSubjectPublicKeyInfo / ImportSubjectPublicKeyInfo，以及完全相同的 sgcMLKEM_* 和 sgcSLHDSA_* 组合X.509 SubjectPublicKeyInfo，因此后量子公钥写入与 RSA 或 EC 公钥相同的结构。对应 RFC 9881、RFC 9909 和 RFC 9935。
私钥导出 & 导入，DERsgcMLDSA_ExportPrivateKeyInfo / ImportPrivateKeyInfo，以及 sgcMLKEM_* 和 sgcSLHDSA_* 配对PKCS#8 OneAsymmetricKey，版本 0 和 1。导入时会检查密钥的一致性：内嵌的公钥若不匹配则被拒绝，同一密钥的种子形式和展开形式必须一致，ML-DSA 密钥必须能重现其存储的 t0 和 tr。SLH-DSA 会根据种子重新计算 PK.root，开销约相当于一次密钥生成，因此这些导入接受一个 aVerify 参数，默认为 True，对于由您自己的应用程序生成的密钥，可以传入 False。
PEM 导出与导入sgcMLDSA_ExportPublicKeyPEM、ExportPrivateKeyPEM、ImportPublicKeyPEM、ImportPrivateKeyPEM，以及对应的 sgcMLKEM_* 和 sgcSLHDSA_* 函数组RFC 7468，即 -----BEGIN ... -----END 包装，因此这些密钥可以直接放进 PKI 其余部分所用的文件与工具链。
私钥形式TsgcPQCPrivateKeyFormatML-DSA 和 ML-KEM 私钥有三种形式。pqkfSeed 只写入种子（ML-DSA 为 32 字节，ML-KEM 为 64 字节的 d||z 种子），pqkfExpanded 写入展开后的密钥，pqkfBoth 两者都带。SLH-DSA 只有一种私钥形式。
返回种子的密钥生成sgcMLDSA_GenerateKeyPairAndSeed、sgcMLKEM_GenerateKeyPairAndSeed在返回密钥对的同时交回种子，因此生成之后就能直接写出种子形式的 PKCS#8 或 PEM 文件。
X-Wing 混合 KEMsgcXWing_GenerateKeyPair、sgcXWing_Encapsulate、sgcXWing_Decapsulatedraft-connolly-cfrg-xwing-kem-10：把 X25519 与 ML-KEM-768 合成为一个 KEM。公钥 1216 字节，私钥 32 字节（即种子），密文 1120 字节，共享密钥 32 字节。
TLS 1.3 混合密钥共享sgcTLSHybrid_ClientKeyShare、sgcTLSHybrid_ServerKeyShare、sgcTLSHybrid_ClientSharedSecret、sgcTLSHybrid_GroupName、sgcTLSHybrid_AvailableRFC 10024 的 X25519MLKEM768、SecP256r1MLKEM768 和 SecP384r1MLKEM1024 组（IANA 代码点 0x11EC、0x11EB、0x11ED）。它们不是独立的 KEM，只用于构建 TLS 密钥共享。
用于 JSON Web Token 的 ML-DSAJWTOptions.Algorithms.MLDSA.PrivateKey、PublicKey、Enabled、sgcMLDSA_ExportPublicJWK、sgcMLDSA_ExportPrivateJWK、sgcMLDSA_ImportJWK、sgcMLDSA_ImportJWKAsPEMRFC 9964，位于 sgcHTTP_JWT_MLDSA，而不是某个 sgcCrypto_* 单元。JWS 算法为 ML-DSA-44、ML-DSA-65 和 ML-DSA-87（jwtMLDSA44、jwtMLDSA65、jwtMLDSA87），客户端使用 PKCS#8 PEM，服务器使用 SubjectPublicKeyInfo PEM，支持 AKP JSON Web Key，整条路径都不涉及 OpenSSL。
已知答案验证NIST ACVP 向量ML-KEM 的密钥生成、封装和解封装，以及 ML-DSA 和 SLH-DSA 的密钥生成、签名生成和签名验证，都会对照 sgcWebSockets QA 套件中的 NIST ACVP 已知答案向量进行检查。

sgcCrypto 不声称支持 ed25519187 或 SPECK。ed25519187 没有公开发布的规范，而 SPECK 已于 2018 年从 ISO 标准化进程中撤回；本库均未实现这两者。

TLS 1.3 和 1.2 引擎

构建在这些单元之上的 TLS 1.3 和 TLS 1.2 栈

它用 Object Pascal 写在 sgcCrypto 原语之上，随同一个产品包提供。它位于 sgcSSL_NativeTLS* 单元，而不是 sgcCrypto_*，因此不计入上面的 43 个单元。

能力API说明
在客户端选用TLSOptions.IOHandler := iohNativeTLS用进程内的 Pascal 引擎取代 OpenSSL、SChannel 和各平台 TLS 后端。任何目标平台上都无需部署任何东西。
在服务器选用SSLOptions.IOHandler := iohNativeTLS可配合默认的 Indy 服务器引擎，也可配合 IOCP 和 EPOLL 引擎。
协议版本TLSOptions.Version允许的最低版本。tls1_2 或 tlsUndefined 会协商 TLS 1.3 或 TLS 1.2，tls1_3 只允许 TLS 1.3，而 tls1_0 或 tls1_1 会引发配置错误。服务器上的 SSLOptions.Version 作用相同。若只需要 TLS 1.2，请在 CipherSuites 中只列出 TLS 1.2 的密码套件。
密钥交换组TLSOptions.NativeTLS_Options.Groups以冒号分隔，采用 OpenSSL 风格。默认值为 X25519MLKEM768:X25519:secp256r1:secp384r1，因此只要对端同意，握手就是后量子混合握手。启用 SGC_CRYPTO_FIPS 的构建则默认使用 SecP256r1MLKEM768:SecP384r1MLKEM1024:secp256r1:secp384r1。这三个混合组仅用于 TLS 1.3，因此 TLS 1.2 连接使用 X25519、secp256r1 或 secp384r1。
密码套件TLSOptions.NativeTLS_Options.CipherSuites以冒号分隔，采用 OpenSSL 风格。TLS 1.3 的默认值为 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256，此外 TLS 1.2 默认包含使用 AES-128-GCM、AES-256-GCM 和 ChaCha20-Poly1305 的 ECDHE_ECDSA 与 ECDHE_RSA 套件。带 AES-CBC 的 ECDHE 套件和 RSA 密钥交换只有在显式指定时才会使用，TLS 1.2 套件共 20 个。启用 SGC_CRYPTO_FIPS 的构建会去掉 ChaCha20-Poly1305 和 RSA 密钥交换。
信任根TLSOptions.RootCertFile、TLSOptions.NativeTLS_Options.UseSystemRoots根证书来自 RootCertFile。将 UseSystemRoots 设为 True，可加入操作系统已经信任的根证书：在 Windows 上是 ROOT 存储，在其他平台上则是在标准位置中找到的第一个 CA 证书包文件。它不会读取 macOS 或 iOS 的钥匙串，也不会读取 Android 的证书存储。它默认关闭，因此 RootCertFile 仍是来源。SSLOptions 上的同一属性适用于服务器所验证的客户端证书。
证书链构建对端发送的证书链会在证书链中搜索从叶证书到信任根的路径，因此额外的证书和任意顺序都可以接受，这正是 RFC 8446 第 4.4.2 节的要求。搜索会回溯，因此一个指明了正确颁发者但走不通的证书，不再会遮住其后面的有效路径。不检查吊销状态和证书策略。
协议范围RFC 8446、RFC 5246TLS 1.3 和 TLS 1.2。不支持 TLS 1.1、TLS 1.0 或 SSL。TLS 1.2 使用 RFC 7627 的扩展主密钥，双方都启用 RFC 8446 的降级保护，拒绝重新协商和 SHA-1 签名（RFC 9155），并以恒定时间校验 CBC 记录。
未实现n/a没有会话恢复，也没有 PSK，没有 0-RTT，没有 QUIC。
对端验证事件OnSSLVerifyPeer对该引擎不可用，它有自己的验证钩子。如果您的代码依赖这个事件，请继续使用 OpenSSL 或某个平台后端。
OTP、编码与杂项

一次性密码、编解码器与加密 ZIP

工具层：一次性验证码、其他分类共用的编码方式，以及 WinZip AES 加密。

能力函数说明
HOTPsgcHOTPRFC 4226，基于计数器的一次性密码。
TOTPsgcTOTP、sgcTOTP_FromBase32RFC 6238，基于时间的一次性密码；Base32 变体可直接接受身份验证器应用显示的那种格式的密钥。
TOTP 验证sgcTOTP_Verify在一个时间步长窗口内以恒定时间检查提交的验证码，因此结果及其所在的位置都不会通过时序泄露。它本身不阻止重放，由调用方跟踪已使用的验证码。
恒定时间比较sgcConstantTimeEquals贯穿整个库，用于标签和 MAC 比较。
安全清零sgcSecureZero覆写字节缓冲区，使密钥材料不会残留在内存中。
十六进制sgcHexEncode / sgcHexDecode小写十六进制，解码时不区分大小写。
Base64urlsgcBase64UrlEncode / sgcBase64UrlDecodeRFC 4648 第 5 节，不带填充，JWT 和 JOSE 所用的编码方式。
Base32sgcBase32Encode / sgcBase32DecodeRFC 4648 第 6 节，TOTP 密钥和身份验证器应用所用的编码方式。
WinZip AES 密钥派生sgcZipAE2_DeriveKeys基于 PBKDF2，从密码和盐值派生密钥、认证密钥和密码验证器。
WinZip AES 加密 / 解密sgcZipAE2_Encrypt / sgcZipAE2_DecryptAE-1 和 AE-2，AES-128/192/256，通过 TsgcZipAESStrength 指定每条目的盐值大小。
WinZip 条目打包sgcZipAE2_PackEntry / sgcZipAE2_UnpackEntry将盐值、验证器、密文和认证码组合成磁盘上的存储布局。
WinZip 附加字段sgcZipAE2_BuildExtraField / sgcZipAE2_ParseExtraField标记某个 ZIP 条目已被 AES 加密的 0x9901 附加字段。
传统哈希（仅供互操作）sgcMD4、sgcMD5、sgcHMAC_MD5为读取旧格式和协议而保留；请勿用于新设计。
传统密码（仅供互操作）sgcDES_EncryptECB / sgcDES_DecryptECB、sgcDES_NTLM7to8DES-ECB 以及基于 DES 的 NTLM 密钥扩展步骤，两者均已被撤回（FIPS 46-3），仅为传统互操作而保留。
安全随机字节sgcRandomBytes / sgcRandomFillMSWINDOWS 下使用 BCryptGenRandom（Windows CNG），其他平台使用 /dev/urandom，两种情况下都是同一次调用。
平台与语言

sgcCrypto 可以在哪里运行

明确说明支持的范围。

方面详情
操作系统在 sgcVer.inc 中，没有任何 MSWINDOWS 防护，也没有任何其他平台防护包裹 SGC_CRYPTO。全部 43 个单元均可为 Win32、Win64、Linux64、macOS、iOS 和 Android 编译。
随机数来源唯一一个感知平台的单元 sgcCrypto_Random，会为每个目标平台选择相应的 CSPRNG：MSWINDOWS 下使用 BCryptGenRandom（Windows CNG），POSIX 目标上使用 /dev/urandom，均隐藏在同一个 sgcRandomBytes 调用之后。这些字节直接来自操作系统的随机数生成器，上层没有任何自有生成器。在 Windows 上，只有当 BCryptGenRandom 不可用时才会依次使用 RtlGenRandom 和 CryptGenRandom；如果无法读取任何来源，将抛出异常，而不会返回弱随机字节。
FIPS 模式可选的条件编译符号 SGC_CRYPTO_FIPS，默认关闭，会在编译时从 43 个单元中移除所有未经批准的算法，并在运行时检查若干参数规则。它让库只保留 FIPS 批准的算法，但 sgcCrypto 并不是经过 FIPS 140-3 验证的模块，该符号也不代表任何验证声明。FIPS 模式
DelphiDelphi 7 至 RAD Studio 13 Florence。任何地方都不假设存在原生的 64 位整数类型：sgcCrypto_Int64 以及 sgcCrypto_BigInteger 中的 TsgcBigInt 类型模拟了哈希、曲线和后量子单元所需的运算。
C++ Builder通过生成的头文件支持 C++ Builder，使用同一份源码树。
设计时占用没有。没有 sgcCrypto_Reg.pas，没有任何东西被 RegisterComponents，也没有任何单元出现在组件面板页面上。
依赖项没有 OpenSSL 绑定，没有外部 DLL。每个原语都直接在您所引用的单元中以 Object Pascal 实现。
源代码每个付费版本都附带完整 Object Pascal 源代码，已包含 sgcCrypto 的版本包也是如此。
再分发您构建的二进制文件可免版税再分发，没有按坐席或按服务器计费的运行时费用。
超值之选：All-AccesseSeGeCe 全部产品，含高级支持，每年 €1,059 起。
查看 All-Access 价格

用 sgcCrypto 构建

下载免费试用版，调用一个函数即可，无需任何组件。

下载免费试用版 查看价格