为何AWS KMS与AWS Encryption SDK无法互相解密密文？

关于AWS Encryption SDK #

AWS Encryption SDK无法解密AWS KMS的Encrypt或ReEncrypt操作返回的密文。同样，AWS KMS的Decrypt操作也无法解密AWS Encryption SDK返回的加密消息。

关于AWS KMS #

Decrypt操作还可以解密使用AWS KMS非对称KMS密钥中的公钥在AWS KMS外部加密的密文。但它无法解密由其他库（如AWS Encryption SDK或Amazon S3客户端加密）生成的密文，这些库返回的密文格式与AWS KMS不兼容。

1. 相同标准算法下，原始密文为何仍有差异？ #

即使选用同一标准加密算法（如AES-256-GCM），密文差异核心来自工具自定义的封装格式与附加元数据：

• AWS KMS的Encrypt接口返回的密文是AWS专属结构化格式，内置了密钥ID、加密上下文、算法标识等元数据，并非纯算法输出的原始密文。
• AWS Encryption SDK遵循自身的消息规范，会将数据密钥、加密上下文、算法信息、签名等内容打包进最终加密消息，封装结构与KMS完全不同。
• 此外，加密时生成的随机初始化向量（IV）、认证标签（如GCM模式的Tag）本身具备随机性，即使加密同一份明文，每次输出的密文也会存在差异，但这属于算法正常特性，工具间的格式差异才是不兼容的核心原因。

2. AWS KMS兼容OpenSSL等库却无法解密其他库密文？兼容范围如何明确？ #

AWS KMS的Decrypt接口能兼容OpenSSL等库，前提是你用KMS非对称密钥的公钥，按照纯标准算法格式加密数据：

• 比如用OpenSSL调用KMS导出的RSA公钥，以标准RSA-OAEP算法加密数据，KMS的Decrypt接口可以识别这种纯标准格式的密文并完成解密。
• 但像AWS Encryption SDK、S3客户端加密这类工具，并非直接用KMS密钥加密原始数据，而是先生成数据密钥（DEK），用DEK加密原始数据，再用KMS密钥加密DEK，最终把加密后的DEK、原始密文、元数据打包成自定义格式的消息。这种整体封装的消息KMS无法识别，自然无法解密。

关于与OpenSSL、BouncyCastle、WolfSSL、mbed TLS等库的兼容范围，核心判断标准如下：

• 符合纯标准算法格式：只要用这些库按照KMS支持的标准算法（如RSA-OAEP、ECIES）直接加密数据，未添加自定义封装，KMS就能解密。
• 涉及工具自定义封装：如果工具像Encryption SDK那样做了多层密钥封装+自定义消息结构，KMS无法处理，因为KMS的Decrypt仅识别自身密文格式，或纯标准算法输出的密文（仅限非对称密钥场景）。

内容的提问来源于stack exchange，提问作者Mohamed Hamzaoui