日志文件加密

Question

我想加密应用程序写入的日志文件的内容。日志系统具有以下特点：

• 文件格式为二进制。
• 当应用程序仍在运行时，日志文件仍处于打开状态。
• 新数据随日志条目的生成而追加。
• 日志条目有不同的长度，我不能用某些密码块大小对齐。
• 当应用程序重新启动时，它必须读取现有的日志文件，了解其内容，并决定是向该文件追加新项还是启动新文件。这需要对称加密。
• 加密密钥必须嵌入到应用程序中，日志文件的接收方必须知道它。所以我想这是一个静态键，至少对于那个应用程序是这样的。
• 解密后的数据不得超过原始明文，否则日志查看器将尝试从其他字节生成另一个完整的日志项。

我想这不允许我使用超级安全的加密。能够从应用程序中提取静态密钥的人(连同所使用的算法)应该能够读取日志文件。但是，日志文件只应该被加密，因为它可能包含可以显示应用程序中应该混淆和编码的内部名称的信息。读取日志文件对消除程序混淆没有帮助.

我在CBC模式下使用AES加密“安全”配置文件，使用静态应用程序密码生成IV并通过Rfc2898DeriveBytes密钥(忘记名称，类似于PBKFD.)。和一个随机的盐一起添加到文件中。但是这些文件总是被读和写成一个整体。它很好地处理填充，但我还不确定它是如何工作的。

我完全不清楚我应该如何在以后添加一个填充加密的文件。我能找到最后一个街区然后以某种方式覆盖它吗？(我在我的应用程序中使用.NET，如果有人知道我在那里能做什么。)

然后我读到了流密码，它一次只处理一个字节。我想我可以在任何时候停止写作，从那时起继续写作。但是，它们似乎通常是不安全的，以至于对数据进行加密是毫无用处的。

在.NET中，我会用一个加密/解密流的实例来封装我的文件流。我不知道这样是否可以对加密的文件进行顺序读写访问。我需要读取一个现有的文件，直到它结束，然后继续只写。这对加密文件有效吗？

那么我应该如何处理我的日志文件的加密呢？是否有适合这种情况的某些算法、模式或方法？

或者我应该用一个静态密钥来异或我的日志文件，就像我们小时候那样，把它叫做“加密”.

更多细节，回复评论：

• 日志文件仅被追加，并最终全部删除。
• 日志条目是二进制的，包括。零字节。例如，一个int32值只需要4个字节。
• 一个日志条目在技术上仅限于256个MiB，但很少有那么大。(文件格式规范在这里。)
• 部分加密就足够了，基本上只有字符串条目需要加密，而不是数字或结构本身。(我还没有想到那个解决方案！)
• 日志查看器可以在日志文件编写时实时读取它们。但是，如果在最后一个完整日志项之后有数据，则它必须是有效的完整日志项。如果它不完整，读者将等待它变得完整。(您可以将每个字节刷新到文件中，日志项将出现在编写的最后一个字节之后。)文件末尾的随机噪声会破坏读取。

考虑到填充物，实时阅读模式尤其有趣。在写入CryptoStream时，流必须缓冲至少一个块大小的数据。如果在完成块之前关闭流，则应追加填充。如果我想冲洗流，但让它保持打开，填充可能不会被移除，这就打破了这个块。

另外，我发现使用.NET CryptoStreams，我既可以读取不可查找的文件，也可以写入文件，而不是两者兼而有之。我无法在溪流中寻找。因此，添加到现有文件可能不会是一个选项。

所以，也许我所需要的是不可能的块密码在块模式。

但是，如果我们找到一种只加密单独的字符串记录的解决方案(这些记录是通过文件偏移量从其他结构引用的，因此它们是可重用的)，那么问题就会缩小到加密单独(大部分是短的)字符串，每次加密在它们自己的记录范围内。我可能更喜欢一个小块大小的算法来使填充开销保持较小。对于这个平台来说，这是另一个问题吗？(新的问题是生成IV并通过所有加密的字符串记录来维护它.)

Answer 1

考虑到只要您在不受信任的环境中运行，您的解决方案就不会真正解决问题。

要附加到一个旧日志文件中，您需要读取最后一个和第二个最后一个块，使用第二个最后一个作为"IV“解密最后一个块，删除填充并开始附加。从覆盖最后一个块开始，您现在可以简单地将新的加密块附加到文件中。对于加密，您再次使用第二个最后(密码文本)块作为"IV“。

请参阅https://en.wikipedia.org/wiki/Block_密码学_模式_的_#密码块操作_链子_.28CBC.29以了解该原则。

Answer 2

然后我读到了流密码，它一次只处理一个字节。我想我可以在任何时候停止写作，从那时起继续写作。但是，它们似乎通常是不安全的，以至于对数据进行加密是毫无用处的。

只使用流密码是行不通的。然而，流密码(具有nonce/IV) + HMAC将。也就是说，每当您停止(或在每次写入之后)，到目前为止，请将密文的HMAC写入另一个文件。

增量计算HMAC是有效的。我不知道.NET中的界面是什么样子，但是在python中我会这样做：

hmac.update(log_ctext) # update the running HMAC state
hmac.digest()          # find the current digest while retaining the state

这意味着当您在启动时解析日志文件以验证HMAC时，您已经准备好在不覆盖任何内容的情况下追加新数据。如果HMAC不匹配，您只需要小心地丢弃整个文件，并生成一个新的nonce/IV。

Answer 3

如果加密日志条目的长度必须与未加密日志条目的长度完全匹配是一个硬约束，那么您需要一个保持长度的加密方案。我建议您使用磁盘加密中最早使用的保长方案之一。它们本质上形成了一个具有可变块长度的可调整块密码，因此它们将是加密可变长度日志条目的完美方法。我建议您使用上一个密文的散列作为对当前日志条目进行加密的调整。

对于非常短的日志条目，您也可以查看格式保护加密。

请注意，这些都不会提供任何完整性保护，除非日志读取器检查的日志条目中存在一些冗余。如果日志读取器检查了一些冗余，那么可调整的可变宽度块密码将提供尽可能好的完整性，因为加密不能增加记录的长度。

如果允许加密稍微增加记录的长度，那么我建议使用经过身份验证的加密方案，如GCM、EAX等。