4. 密码库初始化与全局配置

密码库的初始化不是“调用一个 init 函数”这么简单。它决定了后续所有加解密、签名、随机数、密钥派生操作能否正确、合规、可复现地运行。一个典型的密码库（如 OpenSSL、BoringSSL、国密 SDK、Java JCE Provider、Go crypto 包）在进程启动阶段需要完成四件事：建立全局状态、选定随机数源、加载算法提供者、确定合规模式。这四件事有严格的先后依赖，顺序错了会出现“随机数未播种”“Provider 未注册”“FIPS 自检失败”等难以定位的问题。

初始化顺序：先全局、后提供者、再使用

以 OpenSSL 3.x 为例，推荐的初始化顺序是：先调用 OSSL_LIB_CTX_new() 创建独立的库上下文，再通过 OSSL_PROVIDER_load() 加载 default 或 fips 提供者，最后才创建 EVP 上下文进行加解密。如果先创建 EVP_CIPHER_CTX 再加载 provider，该上下文可能绑定到空提供者，导致 EVP_EncryptInit_ex 返回 0。Java 侧的顺序则是：先 Security.addProvider() 注册 Provider，再 SecureRandom.getInstanceStrong() 获取强随机源，最后 Cipher.getInstance()。Go 的 crypto 包在包初始化阶段自动完成注册，但若使用国密 SM2/SM3/SM4 的第三方库（如 tjfoc/gmsm），仍需显式调用其注册函数。

下面这张图展示了密码库从进程启动到可用的全局配置链路，包含随机数源、提供者加载与合规模式三条并行支路，以及它们汇入算法调用前的依赖关系。

随机数源：密码库的“心脏”

随机数源是密码库中最容易被忽视、却最致命的环节。所有密钥生成、IV、盐值、nonce 都依赖它。配置随机数源时，核心是确定 DRBG（确定性随机比特生成器）类型和熵源。OpenSSL 3.x 默认使用 CTR-DRBG，熵源来自操作系统的 /dev/urandom 或 getrandom()。在 FIPS 模式下，必须使用 FIPS 批准的 DRBG，且需要显式设置：

OSSL_LIB_CTX *ctx = OSSL_LIB_CTX_new();
OSSL_PROVIDER *fips = OSSL_PROVIDER_load(ctx, "fips");
OSSL_PROVIDER *base = OSSL_PROVIDER_load(ctx, "base");
// 设置 DRBG 类型为 CTR-DRBG，摘要算法为 SHA-256
EVP_RAND_CTX *rand = EVP_RAND_CTX_new(
    EVP_RAND_fetch(ctx, "CTR-DRBG", NULL), NULL);
EVP_RAND_instantiate(rand, 256, 0, NULL, 0, NULL);

如果随机数源未正确实例化，RAND_bytes() 会返回 0，此时必须终止密钥生成流程，而不是继续使用未初始化或弱随机数据。一个常见的错误是：在容器环境中，/dev/urandom 可用但熵池未就绪，导致早期启动阶段生成的密钥强度不足。解决办法是在初始化阶段调用 RAND_poll() 或等待 getrandom() 返回，确保熵池已播种。

算法提供者加载与 FIPS/国密模式切换

OpenSSL 3.x 引入 Provider 架构后，算法不再硬编码在 libcrypto 中，而是通过 Provider 动态加载。默认情况下，default Provider 提供全部算法；启用 FIPS 模式时，需要同时加载 fips 和 base Provider，并通过 OSSL_PROVIDER_set_default_search_path() 指定 fips.so 的路径。FIPS 模式的关键在于：加载 fips Provider 时会自动执行 KAT（Known Answer Test）自检，只有自检通过，Provider 才可用。如果自检失败，OSSL_PROVIDER_load() 返回 NULL，此时必须拒绝启动加密服务，而不是回退到 default Provider。

国密模式的切换逻辑类似，但通常由国密 SDK 或 OpenSSL 的 gm Provider 实现。以铜锁（Tongsuo）为例，加载 gm Provider 后，SM2/SM3/SM4 算法即可通过标准 EVP 接口调用。切换模式时需要注意：同一进程内不要混用 FIPS 和国密 Provider 的算法上下文，因为两者的随机数源、自检状态和算法实现可能冲突。推荐做法是：在进程启动时根据配置决定加载哪一组 Provider，运行期间不再切换。

线程安全与资源生命周期管理

密码库的全局初始化通常不是线程安全的。OpenSSL 1.1.0 之后虽然移除了显式的锁回调，但 OSSL_PROVIDER_load() 和 OSSL_LIB_CTX_new() 仍应在单线程中完成，或由应用层加锁保护。多线程环境下，正确的做法是：全局上下文和 Provider 只初始化一次，每个线程创建独立的 EVP_CIPHER_CTX / EVP_MD_CTX。这些上下文不是线程安全的，不能跨线程共享。

资源生命周期方面，需要遵循“后创建先释放”的原则。典型顺序是：先释放所有 EVP 上下文，再 OSSL_PROVIDER_unload()，最后 OSSL_LIB_CTX_free()。如果顺序颠倒，可能出现 Provider 已卸载但仍有上下文引用其算法实现，导致段错误或未定义行为。在长驻服务中，建议将密码库初始化放在服务启动的 init 阶段，将资源释放放在 shutdown 阶段，避免在请求处理路径中反复加载和卸载 Provider。

最后需要强调：密码库的全局配置一旦确定，就应作为进程的“安全基线”固化下来。配置项（Provider 路径、DRBG 类型、FIPS 开关）应通过配置文件或环境变量注入，而不是散落在代码各处。这样在审计和排障时，才能快速回答“这个进程到底用了哪个随机数源、哪个 Provider、是否处于 FIPS 模式”这三个关键问题。