不对称的身份验证加密

Question

我希望保护我的数据不被未经授权的人员更改或阅读。搜索我发现Authenticated Encryption（AE）是一种解决方案 我知道我可以使用任何CCM，GCM或EAX在Crypto ++中进行AE。但我注意到他们使用相同的密钥来加密和解密数据。我不希望这样，我宁愿使用非对称密钥来加密和解密我的数据 如果我使用非对称算法对数据进行签名，然后使用对称算法对其进行加密，我将实现我想要的（哪个应该是安全的，因为它是AtE方法，对吧？）。
但在我这样做之前，是否有任何加密库可以做我想要的？

Answer 1

  

我知道我可以使用... CCM，GCM或EAX进行身份验证加密。但我注意到他们使用相同的密钥来加密和解密数据。我不希望这样，我宁愿使用非对称密钥来加密和解密我的数据。

我所知道的所有方案都将使用对称密码进行批量数据加密。对称密码可以是分组密码或流密码。

我还看到了一些不正确的RSA应用，其中RSA在ECB模式下运行。也就是说，数据被“分块”或“阻塞”，然后RSA应用于每个块。 Handbook of Applied Cryptography特别警告这一点。

您可能要做的最好的事情是Elliptic Curve Integrated Encryption Scheme (ECIES)或Discrete Log Integrated Encryption System (DLIES)。两者都以Crypto ++提供。两者都使用公钥（非对称）加密。

ECIES和DLIES将密钥封装机制（KEM）与数据封装机制（DEM）相结合。系统从公共秘密独立地导出对称密码密钥和MAC密钥。首先在对称密码下对数据进行加密，然后在认证方案下对密文进行MAC加密。最后，公共秘密在公钥/私钥对的公共部分下加密。加密函数的输出是元组{K,C,T}，其中K是加密的公共秘密，C是密文，T是认证标记。

有一些人放弃了“共同秘密”，因为它实际上是应用密钥协议功能并随后用KDF消化的结果。它使用静态公钥和短暂密钥对。执行解密的人使用他们的公钥来执行密钥交换的另一半以达到“共同秘密”。

KEM和DEM避免填充，因此填充神谕不是问题。这就是KDF被用来消化KEM下的大“共同秘密”的原因。省略填充大大简化了系统的安全性证明。由于安全性证明，ECIES和DLIES是IND-CCA2，这是您可以实现的最强的之一。

  

如果我使用非对称算法对数据进行签名，然后使用对称算法对其进行加密......

这是一些相关的阅读......首先是Hugo Krawczyk的The Order of Encryption and Authentication for Protecting Communications。其次是Don Davis'Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML。

这里的相关性是：Krawczyk的论文涉及对称密钥加密和加密 - 然后验证样式的验证加密（以及如何执行验证加密）。戴维斯的论文涉及非对称加密以及签名和加密（以及如何修复）之间的脱节。

  

但在我这样做之前，是否有任何加密库可以做我想要的？

是（但这取决于你想做什么）。 Crypto ++是我所知道的唯一提供ECIES，DLIES和PSSR集合的人。

Bouncy Castle紧随其后，因为它提供ECIES，但不提供DLIES。我不确定它提供了多少PSSR。

Crypto ++，Bouncy Castle，OpenSSL（和其他）提供PSSR。使用PSSR找到一个lib应该没有任何问题。

Answer 2

您可以考虑使用基于OpenPGP的解决方案。这将为您提供所需的功能，并可扩展以支持任意数据大小，这与纯粹基于非对称加密（没有传输密钥）的解决方案不同。

有一些开源实现。 BouncyCastle提供了一个，但我不确定他们是否有C ++实现。

Answer 3

GPGME（GnuPG轻松自如）。它是C语言中的高级加密库，并且是LGPL许可的。