不对称身份验证加密

Question

不对称身份验证加密

c++authenticationencryptioncryptographycrypto++

5

我希望保护我的数据不被未授权的人更改或读取。搜索后，我发现认证加密（AE）是一种解决方案。
我知道可以使用Crypto++中的CCM、GCM或EAX进行AE。但我注意到它们使用相同的密钥来加密和解密数据。我不想这样做，我宁愿使用非对称密钥来加密和解密我的数据。
如果我使用非对称算法签名数据，然后使用对称算法加密它，我将实现我想要的（因为这是AtE方法，对吗？）。
但在我这样做之前，是否已经有实现我想要的功能的加密库了呢？

- atoMerz

1

认证-然后加密往往会有问题。我更愿意对明文进行签名，然后使用认证加密同时加密。 - CodesInChaos

1

相关问题：http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign - CodesInChaos

@CodesInChaos，这是我最初想到的，但这是否过度完成了我需要做的事情？ - atoMerz

@owlstead 如果我错了，请纠正我。RSA使用公钥加密数据，因此每个人都应该能够生成一个AES密钥，用RSA加密它，执行GCM并将其发送给Bob。 Bob会认为这是Alice的有效消息，因为他可以解密密钥并将其与GCM一起使用以验证发送的消息。 - atoMerz

1

但是对于数据签名，RSA使用私钥。这就是签名的概念来源。 - atoMerz

@AtoMerZ：没错，可能是我在睡觉或者什么的 :) 我不应该在那种时候发帖。 - Maarten Bodewes

3个回答

1

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

目前有一些开源实现可供选择。BouncyCastle提供了其中之一，但我不确定他们是否有C++实现。

- Duncan Jones

我之前只搜索了BouncyCastle，但现在我注意到也有C/C++的实现，你能解释一下如何用它来达到我的目的吗？ - atoMerz

我认为最好的方法是在阅读协议后，简单地查看CLI应用程序如何执行加密和签名。 - Maarten Bodewes

1

GPGME（GnuPG Made Easy）是一款高级的C语言加密库，采用LGPL许可证。

- jbtule

是的，我已经找到了。你知道我要找的函数名是什么吗？ - atoMerz

gpgme_op_encrypt_sign 和 gpgme_op_decrypt_verify。 - jbtule

感谢提供链接。然而，我仍然不明白其中的几个要点。你的链接说“encryp_sign”，但实际页面只谈论加密。另外，“decrypt_verify”是如何工作的？我没有看到任何传递给它的密钥。 - atoMerz

向下滚动，再往下找 gpgme_op_encrypt_sign，你需要阅读手册以获取所有信息。 - jbtule

谢谢，作为回答的一部分添加注释将不胜感激。这将有助于其他人。 - atoMerz

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jww · Accepted Answer

我知道可以使用CCM、GCM或EAX进行认证加密，但我注意到它们使用相同的密钥来加密和解密数据。我不想这样做，我宁愿使用非对称密钥来加密和解密我的数据。

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

我也看到了一些错误的RSA应用程序，其中RSA在ECB模式下运行。也就是说，数据被“分块”或“分段”，然后对每个块应用RSA。应用密码学手册明确警告了这一点。

你可能能够做到最好的是椭圆曲线综合加密方案（ECIES）或离散对数综合加密系统（DLIES）。两者都可在Crypto++中使用，都使用公钥（非对称）密码学。

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

关于“共同秘密”，实际上它是应用密钥协商功能得出的结果，并随后使用KDF进行摘要处理。它使用静态公钥和临时密钥对。执行解密操作的人使用其公钥执行密钥交换的另一半，以得到“共同秘密”。

KEM和DEM避免填充，因此填充奥拉克尔不是一个问题。这就是为什么在KEM下使用KDF来消化大型“公共秘密”的原因。省略填充极大地简化了系统的安全证明。由于安全证明，ECIES和DLIES是IND-CCA2，这是您可以实现的最强安全性之一。

如果我使用非对称算法签署数据，然后使用对称算法加密它...这里有一些相关阅读材料...首先是Hugo Krawczyk的加密和认证保护通信的顺序。第二个是Don Davis的S/MIME、PKCS#7、MOSS、PEM、PGP和XML中有缺陷的签名和加密。

这里的相关性是：Krawczyk的论文涉及对称键密码学和“先加密再验证”式的认证加密（以及如何执行认证加密）。Davis的论文涉及非对称密码学和签署和加密之间的脱节（以及如何修复它）。

在我提供方案之前，有没有已经有的加密库能够满足你的需求？

是的（但这取决于你想做什么）。Crypto ++ 是唯一我知道的提供ECIES、DLIES和一系列PSSR的库。

Bouncy Castle 是第二选择，因为它提供了ECIES，但没有DLIES。我不确定它提供了多少个PSSR。

Crypto ++、Bouncy Castle、OpenSSL（以及其他一些库）都提供PSSR。你不应该有任何问题找到带有PSSR的库。