22、加密与哈希：OpenSSL、libsodium的跨平台编译与API调用

加密这事儿，说白了就是给数据加把锁。哈希呢，就是给数据打个指纹。我在做跨平台项目时，最头疼的不是算法本身，而是怎么让这些加密库在Windows、Linux、macOS甚至嵌入式系统上都能老老实实地工作。

今天咱们就聊聊OpenSSL和libsodium这两个库。一个老牌劲旅，一个后起之秀。嗯，我两个都用过，各有各的脾气。

22.1 为什么选这两个库？

你想想看，市面上加密库那么多，为什么我偏偏推荐这两个？

• OpenSSL：行业标准，几乎所有的Linux发行版都自带。但它的API设计嘛...说实话，有点老派。我在项目中遇到过好几次因为版本升级导致API不兼容的问题。
• libsodium：现代、简洁、安全。它的设计哲学就是「让开发者难以用错」。我个人习惯在新项目中优先考虑libsodium。

22.2 跨平台编译：从源码开始

依赖包管理器？别闹了。跨平台项目最忌讳的就是依赖系统自带的库。版本不一致、编译选项不同，这些坑我都踩过。

22.2.1 编译OpenSSL

OpenSSL的编译系统用的是Perl脚本。我第一次看到时也愣了一下，但用顺手了其实挺灵活的。

# Linux/macOS
./Configure linux-x86_64 --prefix=/usr/local/openssl
make -j$(nproc)
make install

# Windows (使用MSYS2或Visual Studio命令行)
perl Configure VC-WIN64A --prefix=C:\openssl
nmake
nmake install

# 交叉编译到ARM
./Configure linux-armv4 --prefix=/usr/local/openssl-arm \
  --cross-compile-prefix=arm-linux-gnueabihf-
make -j4
make install

22.2.2 编译libsodium

libsodium的编译就友好多了。它用的是autotools，但同时也提供了CMake支持。

# Linux/macOS
./configure --prefix=/usr/local/libsodium
make -j$(nproc)
make install

# Windows (CMake方式)
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=C:\libsodium
cmake --build . --config Release
cmake --install .

# 交叉编译
./configure --host=arm-linux-gnueabihf \
  --prefix=/usr/local/libsodium-arm
make -j4
make install

22.3 API调用实战

好了，库编译好了，咱们来看看怎么用。我挑几个最常用的场景来讲。

22.3.1 哈希计算

哈希是最基础的操作。文件完整性校验、密码存储，都离不开它。

// OpenSSL: SHA-256
#include <openssl/sha.h>

void hash_openssl(const unsigned char *data, size_t len) {
    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256(data, len, hash);
    // hash里就是结果
}

// libsodium: 通用哈希
#include <sodium.h>

void hash_libsodium(const unsigned char *data, size_t len) {
    unsigned char hash[crypto_generichash_BYTES];
    crypto_generichash(hash, sizeof(hash), data, len, NULL, 0);
    // 更安全，默认使用BLAKE2b
}

看到区别了吗？OpenSSL的API直接指定了算法，而libsodium用的是常量。我个人更喜欢libsodium的方式——你不需要记住算法细节，只要知道「我要一个哈希」就够了。

22.3.2 对称加密

对称加密，说白了就是加密和解密用同一个密钥。AES是主流。

// OpenSSL: AES-256-GCM
#include <openssl/evp.h>

int encrypt_openssl(const unsigned char *plaintext, int plaintext_len,
                    const unsigned char *key, const unsigned char *iv,
                    unsigned char *ciphertext, unsigned char *tag) {
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL);
    EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL);
    EVP_EncryptInit_ex(ctx, NULL, NULL, key, iv);
    
    int len;
    EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len);
    EVP_EncryptFinal_ex(ctx, ciphertext + len, &len);
    EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag);
    
    EVP_CIPHER_CTX_free(ctx);
    return 1;
}

// libsodium: XChaCha20-Poly1305
#include <sodium.h>

int encrypt_libsodium(const unsigned char *plaintext, int plaintext_len,
                      const unsigned char *key, const unsigned char *nonce,
                      unsigned char *ciphertext) {
    // 加密和认证标签一起输出
    crypto_aead_xchacha20poly1305_ietf_encrypt(
        ciphertext, NULL,
        plaintext, plaintext_len,
        NULL, 0, NULL, nonce, key);
    return 1;
}

22.3.3 非对称加密与签名

非对称加密，公钥加密私钥解密。签名则是私钥签名公钥验证。

// OpenSSL: RSA签名
#include <openssl/rsa.h>
#include <openssl/pem.h>

int sign_openssl(const unsigned char *msg, size_t msglen,
                 const char *privkey_path, unsigned char *sig) {
    FILE *f = fopen(privkey_path, "r");
    RSA *rsa = PEM_read_RSAPrivateKey(f, NULL, NULL, NULL);
    fclose(f);
    
    unsigned int siglen;
    RSA_sign(NID_sha256, msg, msglen, sig, &siglen, rsa);
    RSA_free(rsa);
    return siglen;
}

// libsodium: Ed25519签名
#include <sodium.h>

int sign_libsodium(const unsigned char *msg, size_t msglen,
                   const unsigned char *secret_key, unsigned char *sig) {
    crypto_sign_detached(sig, NULL, msg, msglen, secret_key);
    return crypto_sign_BYTES;
}

嗯，这里要注意。OpenSSL的RSA签名需要加载PEM文件，处理密码回调...而libsodium直接操作字节数组。如果你在做嵌入式开发，文件系统可能都没有，libsodium的方式显然更合适。

22.4 跨平台兼容性清单

我在多个平台上折腾过这两个库，总结了一张表给你参考：

平台	OpenSSL	libsodium	注意事项
Linux x86_64	✅ 原生支持	✅ 原生支持	系统自带OpenSSL，但版本可能较旧
Windows	✅ 需编译	✅ 需编译	OpenSSL用nmake，libsodium用CMake
macOS	✅ 需编译	✅ 原生支持	Homebrew可安装，但建议静态编译
ARM Linux	⚠️ 交叉编译	✅ 交叉编译	OpenSSL的汇编优化代码需要针对性配置
嵌入式RTOS	❌ 太重	⚠️ 需裁剪	libsodium有最小化编译选项

22.5 避坑指南

这些年踩过的坑，我挑几个典型的说说：

• 随机数生成：OpenSSL的RAND_bytes在初始化前需要播种。我曾经在容器化环境中忘记调用RAND_poll，结果每次启动生成的密钥都一样。libsodium的randombytes_buf会自动从系统熵源获取随机数，省心多了。
• 内存安全：加密操作涉及敏感数据。用完一定要清零。OPENSSL_cleanse和sodium_memzero都能防止编译器优化掉清零操作。别用memset，编译器可能会把它优化掉。
• 线程安全：OpenSSL默认不是线程安全的。需要调用CRYPTO_set_locking_callback设置锁回调。libsodium在设计上就是线程安全的，不需要额外配置。
• 版本兼容：OpenSSL 1.0.x和1.1.x的API有变化。我建议统一使用1.1.1或3.x。libsodium的API一直很稳定，从1.0.0到现在基本没变过。

22.6 知识体系图

下面这张图展示了加密与哈希的核心知识结构，以及OpenSSL和libsodium的定位：

22.7 总结

加密库的选择，说白了就是权衡。OpenSSL功能全面，但API复杂，适合需要兼容旧系统的场景。libsodium现代简洁，适合新项目，尤其是跨平台和嵌入式开发。

我个人现在的习惯是：新项目一律用libsodium。除非客户明确要求OpenSSL，或者需要跟已有的OpenSSL系统对接。你想想看，少踩一个坑，就能多睡一个好觉，对吧？

---

公众号:蓝海资料掘金营，微信deep3321