使用EC_KEY与EVP_PKEY验签结果不一致的原因排查

• 公钥加载流程错误
  切换到EVP_PKEY后，若仍沿用EC_KEY的加载逻辑（比如先构造EC_KEY再尝试转换），很容易出问题。正确的做法是直接从DER/PEM格式加载EVP_PKEY：

  • 先将Base64编码的公钥解码为DER二进制数据
  • 调用d2i_PUBKEY(NULL, &der_buf, der_len)直接生成EVP_PKEY对象，避免使用已弃用的EVP_PKEY_get1_EC_KEY转换函数。如果手动指定密钥类型或曲线参数时出错，会导致公钥无效，直接引发验证失败。

• 验证上下文的算法配置不匹配
  使用EVP_MD_CTX进行验证时，必须在EVP_DigestVerifyInit中明确指定与签名生成时一致的摘要算法（比如EVP_sha256()）。EC_KEY的验证函数（如ECDSA_verify）可能会隐式适配算法，但EVP_PKEY要求显式配置，若算法不匹配，验证必然失败。

• 签名数据格式不兼容
  EC_KEY的ECDSA_verify通常接受原始r/s拼接格式的签名，而EVP_PKEY的EVP_DigestVerify要求签名是ASN.1 DER编码格式。如果你的签名数据是原始r/s格式，直接传给EVP接口会导致验证失败，需要先用ECDSA_SIG_to_DER将原始签名转换为DER格式后再传入。

• OpenSSL 3.0提供者机制影响
  OpenSSL 3.0引入了提供者（Provider）架构，默认的default提供者可能不支持某些旧版椭圆曲线或算法。如果你的公钥使用了较旧的曲线，需要显式加载legacy提供者：

  OSSL_PROVIDER_load(NULL, "legacy");
  

  未加载对应提供者会导致EVP_PKEY无法正确解析公钥或执行验证逻辑。

• 内存或上下文管理疏漏
  EVP系列接口对内存管理的要求更严格，比如未正确初始化EVP_MD_CTX（需调用EVP_MD_CTX_new()而非直接分配结构体）、未在使用后正确释放资源，或者公钥对象被提前释放，都可能导致验证过程中出现隐性错误。

内容的提问来源于stack exchange，提问作者Mạnh Đỗ Duy