加密和数据完整性: h=CRC-8(m)和c=Encrypt(k，m)然后通过信道发送(h，c) .安全？

Question

m := plaintext message
c := Encrypt(k,m) (AES-128 in counter mode)
k := Key (16 Byte)
h1 := CRC-8/16/32(m)
h2 := CRC-8/16/32(c)

如果我通过一个通道发送(

，c)，这是安全的吗？

CRC-8/16/32是线性相关的，我们在明文上构建它，所以我想我可以得到一些关于m或k只有c和h的信息，对吗？

如果我通过一个通道发送(

，c)，这是安全的吗？

这不可能更好，因为如果是这样，那么中间的人就可以简单地创建一个有效的(h2，c)对，而如果我们发送(h1，c)，他需要知道明文来计算一个有效的CRC？

问题

如果有一个系统，就像上面提到的两种，那么中间人怎么能攻击这个系统呢？一些例子和/或数学是值得赞赏的！

我知道在实际系统中不能使用CRC进行身份验证，这是一个理论问题。有人使用CRC而不是真正的MAC。我只想了解(坏的) CRC解决方案的风险。(与数学有关的细节)

Answer 1

你们的两项计划都有缺陷，这并不是因为CRC。如果用加密哈希函数替换CRC，则您的方案仍然不安全。

1. 哈希(M)+加密(m，k) 1加密的目的是保证明文消息的保密性。只有通过破解128位键才能显示消息。相反，散列与键无关。如果可能的明文数量是有限的，那么攻击者就可以很容易地蛮力地强迫明文。由于哈希函数不接受密钥作为输入，而且AES对已知的明文攻击是安全的，因此无法从哈希获取有关密钥的任何信息。
2. 散列(加密(m，k)) +加密(m，k)这里的散列函数不能保证密文的真实性，因为任何人都可以计算哈希。与以前的方案不同，此散列不会降低加密的安全性。

如果您的目标是真实性，修改第二个方案使用HMAC而不是CRC。或者不要使用单独的MAC，在GCM模式下使用AES代替CTR。