我正在考虑使用AES256 CBC + HMAC SHA-256作为消息的构建块，以确保机密性和身份验证。
特别要考虑这种情况：
现在，对于Bob希望发送Alice的每个数据包，他执行以下操作：
Alice还计算了K（e）和K（s），并在从Bob接收数据时遵循以下程序：
这个协议是否确保Alice只解密来自Bob的消息，假设除了Bob之外没有人可以读取Alice使用他的公钥加密的加密消息？
即。以这种方式构造的消息是否确保了机密性和身份验证？
注意：如果协议要求Bob发送多条消息，则需要稍加修改此方案以避免重放攻击。
P.S。我知道AES-GCM / CCM，但这种方案适用于大多数加密软件包中的基本AES，SHA和HMAC算法。此解决方案也可能较慢，但这也不在问题的范围内。
答案 0 :(得分：18)
基本上你正在重新创建SSL/TLS。这意味着关于构建自己的协议的常见警告，我们热烈鼓励您将TLS与现有库一起使用，而不是重写自己的库。
话虽如此，使用带有CBC的AES进行加密，使用HMAC进行完整性，是合理的。有结合加密+完整性模式（你知道），而CBC + HMAC是一种“老派”，但它不会受到伤害。你正在以“科学认可”的方式做事：加密，然后MAC 加密的字符串（你不要忘记IV：忘记IV是 经典错误）。
你的密钥推导可能有点弱。如果SHA-256表现得像一个完美的随机oracle，那就完美了，但是众所周知，SHA-256 不的行为就像一个随机的oracle（因为所谓的长度扩展攻击）。它类似于HMAC是HMAC的原因，具有两个嵌套的散列函数调用，而不是简单的散列（一次）MAC密钥和数据的串联。 TLS使用特定的密钥派生函数（在TLS规范中称为“PRF”），这应避免任何麻烦。该功能基于SHA-256（实际上，通过HMAC / SHA-256）构建，可以在任何典型的SHA-256实现中实现。
（我并不是说我知道如何攻击你的密钥推导过程;只是认为这是一个棘手的事情，并且只有经过数百名密码学家多年的审查才能评估其安全性。这就是为什么重用已经彻底检查的功能和协议基本上是一个好主意。）
在TLS中有两个 nonce，称为“client random”和“server random”。在您的提案中，您只有“客户端随机”。你在这里失去的安全性，有点不清楚。谨慎的策略是随机包括服务器（即Bob选择的另一个nonce）。我们想要避免的事情是Alice和Bob在两个方向上运行协议，并且攻击者自己将Alice的消息传递给Alice。对攻击者可以做什么的完整分析是复杂的（它是密码学的一个完整分支）;一般来说，两个方向的随机数都倾向于避免一些问题。
如果发送多个数据包，则可能会遇到丢包，重复数据包（“重放攻击”）和无序到达数据包的问题。在TLS的上下文中，这不应该“正常”发生，因为TLS用于已经确保（在正常条件下，不计算主动攻击）数据按严格顺序传输的介质上。因此，TLS包括进入MAC的数据中的序列号。这将检测攻击者的任何更改，包括重播，丢失记录和记录重新排序。如果可能，您还应该使用序列号。
答案 1 :(得分：2)
所述问题的答案是否定的，不能保证Alice只会解密来自Bob的消息，但这只是因为你没有规定只有 Bob知道 K < / em>的。如果Alice和Bob是唯一知道 K 的两个人，那么问题的关键在于你的密钥生成协议是否合理。 （我相信，我们可以忽略其余部分，因为您只是使用HMAC-SHA256和AES256，因为它们是打算使用的。）
生成协议不错，但可以改进。从共享机密创建密钥的可接受方法是使用“key derivation function”。这些函数使用哈希的方式与您在此处所做的相似，但它们也有意缓慢地抑制暴力攻击。 PBKDF2似乎是你想要的，因为a）可以得到512位密钥数据（或更多），b）可以由你可用的原语组成;即SHA256和HMAC-SHA256。
答案 2 :(得分：0)
如果您不想使用PKI，请查看TLS-PSK。它似乎可以解决您自己解决的确切问题。请参阅RFC 4279（以及其他密码套件的5487）。