Nuo*_*oji 13 security cryptography aes hmac
我正在考虑使用AES256 CBC + HMAC SHA-256作为消息的构建块,以确保机密性和身份验证.
特别要考虑这种情况:
现在,对于Bob希望发送Alice的每个数据包,他执行以下操作:
Alice还计算了K(e)和K(s),并且在从Bob接收数据时遵循以下过程:
该协议是否确保Alice仅解密来自Bob的消息,假设除了Bob之外没有人可以读取Alice使用他的公钥加密的加密消息?
即以这种方式构建的消息是否确保机密性和身份验证?
注意:如果协议要求Bob发送多条消息,则需要稍加修改此方案以避免重放攻击.
PS我知道AES-GCM/CCM,但这种方案适用于大多数加密包中的基本AES,SHA和HMAC算法.此解决方案也可能较慢,但这也超出了问题的范围.
Tho*_*nin 19
基本上您正在重新创建SSL/TLS.这意味着关于构建自己的协议的常见警告,并且我们热烈鼓励您将TLS与现有库一起使用,而不是重写您自己的库.
话虽这么说,使用AES和CBC进行加密,HMAC用于完整性,是合理的.有结合加密+完整性模式(你知道),而CBC + HMAC是一种"老派",但它不会受到伤害.你正在做的事情,在"科学认证"的方式:加密,然后MAC的加密字符串(你不要忘了IV:遗忘IV是在经典的错误).
你的密钥推导可能有点弱.这是完美的,如果SHA-256的行为就像一个完美的随机预言,但众所周知,SHA-256并没有表现得像一个随机预言(因为所谓的长度扩展攻击).它类似于HMAC是HMAC的原因,具有两个嵌套的散列函数调用,而不是简单的散列(一次)MAC密钥和数据的串联.TLS使用特定的密钥派生函数(在TLS规范中称为"PRF"),这应避免任何麻烦.该功能基于SHA-256(实际上,通过HMAC/SHA-256)构建,可以围绕任何典型的SHA-256实现实现.
(我并不是说我知道如何攻击你的密钥推导过程;只是认为这是一个棘手的事情,并且只有经过数百名密码学家多年的审查才能评估其安全性.这就是为什么重用功能和已经彻底检查的协议基本上是个好主意.)
在TLS中有两个 nonce,称为"客户端随机"和"服务器随机".在您的提案中,您只有"客户端随机".你在这里失去的安全性,有点不清楚.谨慎的策略是随机包含服务器(即Bob选择的另一个nonce).我们想要避免的事情是Alice和Bob在两个方向上运行协议,并且攻击者自己将Alice的消息传递给Alice.对攻击者可以做什么的完整分析是复杂的(它是密码学的一个完整分支); 一般来说,两个方向的随机数往往会避免一些问题.
如果您发送了几个数据包,那么您可能会遇到一些有关丢失数据包,重复数据包("重放攻击")和无序到达数据包的问题.在TLS的上下文中,这不应该"正常"发生,因为TLS用于已经确保(在正常条件下,不计算主动攻击)数据按严格顺序传输的介质上.因此,TLS包括进入MAC的数据中的序列号.这将检测攻击者的任何更改,包括重播,丢失记录和记录重新排序.如果可能,您还应该使用序列号.