【问题标题】:File encryption with AES-256-CBC vs Chunk encryption使用 AES-256-CBC 的文件加密与块加密
【发布时间】:2018-05-24 09:48:52
【问题描述】:

首先这是我在这里的第一个问题,我希望我可以让您清楚地了解问题并帮助可能面临类似挑战的其他人!问题的标题也是最短的 TL;我能得到的 DR :-)

所以为了给你一些背景信息,我基本上是在设计一个协议,该协议需要从服务器(在 Node.js 中实现)到设备的同步和有序文件传输,通过 TCP。流式传输文件不是一种选择,因此每个文件块都封装在具有其他未加密字段的消息中,这些字段超出了此问题的范围。

其中一个要求是文件内容不能以纯文本形式发送,因此必须选择加密方案,在这种情况下我选择 AES-256-CBC,假设出于这个问题的目的,算法不能改变。

由于设备限制(RAM ~10KB),需要将文件()分割成块,然后根据上述协议发送到设备,遵循发送/[ack|repeat] 方案。在接收时,设备能够将块存储在磁盘上。

所以我的主要问题是在后端我必须选择:

  • 加密整个文件,然后将其拆分成块

    -> 在接收设备上会将每个块附加到文件中,然后在收到所有块时对其进行解密。

对比

  • 将文件分成块,然后对每个块进行加密。

    -> 需要发送用于每个块加密的初始化向量 (IV) 以便对其进行解密。

    -> 在接收块时,设备必须解密该块或将它们中的每一个与各自的 IV 一起存储,然后在接收到最后一个块后解密它们。

这里的目标是了解每种方法会产生哪些安全问题,以及它们之间的开销比较。

PS:我也有一个完整性验证方案,但不在问题范围内。

【问题讨论】:

  • 我暂时删除了我的答案,因为鉴于您的新信息,它不再相关。我会尽快发布新答案。
  • 好的,感谢您的意见和理解! @LukeJoshuaPark
  • 您可以使用流加密模式并以这种方式加密整个套接字流。这更好,因为不再需要处理块和填充。 .NET 没有内置流模式,但流行的加密库支持它。您可以继续使用 AES。
  • 目标不是加密所有消息数据,而是加密其中的一些字段,这就是加密套接字方法在这种情况下无效的原因@usr
  • 您能否再次澄清为什么不能选择流式传输以及为什么您认为需要 ACK?我也不太明白你所说的“块”到底是什么意思。您是否有一大块加密数据,然后是一大块未加密数据等等?

标签: security encryption tcp aes cbc-mode


【解决方案1】:

要回答您的问题,除了我的其他评论中的密钥 AES 问题之外,我认为最好的方法是第二种解决方案。但在你的情况下,我将为每个块添加一个 HAMC。所以:

  • 将文件分成块
  • 为每个块生成一个 IV
  • 使用相应的 IV 和 AES 密钥加密块
  • 添加一个 HMAC(使用与加密不同的 AES 密钥,因此您需要 2 个 AES 密钥)计算每个块的 IV+Cipher_text(使用加密块而不是清除块很重要)李>
  • 发送您的数据块
  • 在设备上接收你的区块。
  • 检查每个块的 HMAC(这样它将确认块没有损坏并且经过良好的身份验证)
  • 使用第一个密钥和相应的 IV 解密块
  • 添加所有块以获取您的原始文件。

第二个更安全,因为您可以在解密之前控制所有块。

我的意思是,如果您逐块加密并添加 HMAC,当您在设备上收到一个块时,首先检查 HMAC,如果没问题,您可以解密该块。这样,如果有人在您的网络上并试图破坏或任何其他块,HMAC 可以验证加密块的来源和内容。

虽然您的第一个选项无法做到这一点。如果有人在传输过程中试图破坏一个块,那么,最好的情况是你不能解密你的全局块,最坏的情况是它可以给黑客一些关于加密系统的信息。对于攻击者来说,这只是一个难题。这还不够,他需要更多的尝试才能期望自己解密一个块,但这是有风险的。

【讨论】:

  • 感谢您的回答,因为它解决了问题上讨论的要点,您能否澄清选择第二个选择的理由是什么?
  • 我已经直接修改了我的答案,因为我的消息太长,无法简单评论。
  • 我已经接受了你的回答,因为我发现它更完整,因为它直截了当,还提供了一种实现方法。
【解决方案2】:

我觉得这个问题的某些部分缺失有助于更好地了解问题,但从表面上看,根据提供的信息,您可能会更好地使用 第二个 选项。

使用第一个选项,您会限制方案的延展性,因为对于给定的块,由于使用 CBC 模式,您不太可能即时解密内容。虽然目前这可能不是您的方案的要求,但可能将来会出现。

使用第二个选项,您可以将数据作为独立的 blob 传递。您可以随意对这些 blob 进行加密和解密,并在必要时将它们组合起来。

每个选项可能还有更多的优点/缺点,但您提供的方案详细信息无法让您有机会了解它们是什么。我建议你谨慎行事。我知道您正在开发的设备有非常严格的要求,这使得传统密码学成为一种失传的奢侈品,但是要正确地设计和实施自己的密码系统非常困难,尤其是在如此严格的要求下。听起来您的方案没有提供前向保密,这意味着如果迫在眉睫,任何其他问题都可能是灾难性的。

【讨论】:

  • 谢谢你的回答卢克!你是对的,我正在处理严格的要求,这就是为什么很难设计这个,更重要的是要证明所做的每个决定是正确的,这是我的目标,尽可能地通过社区反馈来支持我的决定。例如,如果我可以使用 HTTPS,那就太棒了,但它就是这样 :D
猜你喜欢
  • 1970-01-01
  • 2013-08-11
  • 1970-01-01
  • 2017-08-28
  • 1970-01-01
  • 2014-04-10
  • 2021-06-07
  • 2021-04-22
  • 2017-08-28
相关资源
最近更新 更多