【问题标题】:Encrypt/Decrypt Beginner Questions加密/解密初学者问题
【发布时间】:2011-07-08 19:31:41
【问题描述】:

我从来没有做过任何加密或解密,所以我决定尝试做一些类似于 FolderLock 的东西。以下题多为设计题,但夹杂一些编码题。

http://www.newsoftwares.net/folderlock/

无论如何,我还处于初始阶段,有几个初步问题。

  1. 加密文件夹时,实际上是在加密文件夹内的所有文件,而不是文件夹本身,因为文件夹无法加密。对吗?

  2. 另外,我已经编写了我的加密/解密代码,但我想同时包含一个密码。我的计划是,当用户选择一个文件夹/文件进行加密时,让他们设置一个密码,该密码将链接到解密文件夹/文件所需的密钥。好主意还是坏主意?有人有更好的建议吗?我正在讨论为程序本身设置一个密码,该密码也可以解锁任何加密的文件/文件夹......

  3. 如何更改 Windows 7 中的文件夹(我已加密)以在打开时询问密码,而不仅仅是打开并显示所有加密文件?

  4. 最后,当你加密一个文件时,(我的代码目前是如何编写的)你最终会得到你加密的原始文件和该文件的加密版本。我确定我知道这个问题的答案,但是我要删除原始版本并保留加密版本吗?如果由于某种原因解密失败并且我没有文件备份怎么办?我也应该创建文件备份吗?

感谢您的帮助!我确实尝试谷歌搜索上述问题,但似乎大多数这样做的人都比我高得多,所以我没有找到很多有用的答案。

编辑:让我解释一下,虽然我正在尝试创建类似于 FolderLock 的东西,但这只是为了我的教育。我不是想创建一个商业上可行的应用程序,只是在做一些有趣的事情并同时学习。

【问题讨论】:

  • 备份文件会破坏加密它们的全部目的。此外,您不应该简单地删除文件,还要用零填充它。
  • @Ivan:我想这是真的。至于删除文件,我已经有了一种非常安全的删除文件的方法,但我很感激您的意见。
  • 我更新了我对您问题的一些答案,我在第一个答案中省略了它们。我觉得 vcsjones 缺乏很多深度。
  • @CODE:在应用程序级别,不可能有一种真正安全的删除内容的方法,所以我希望你做对了。此外,请确保让专家审查您的最终协议,因为很容易弄错加密 - 而且您可以确定已经有很多加密方案。
  • @owlstead:我将文件归零并将其从 HD 和内存中删除。我认为这已经是我能做到的最深了,至少现在是这样。

标签: c# .net visual-studio-2008 encryption


【解决方案1】:

如何加密文件和文件夹并不是一个只有一个答案的问题。当我们谈论 Windows 环境时,您可以在大约三个不同的级别对文件进行加密:

  1. Hard disk Encryption:在这种情况下,您将加密整个硬盘,这意味着整个磁盘都已加密。 BitLocker 就是一个例子。在这种情况下,您将加密除主引导记录之外的所有内容。写入硬盘的每个字节都经过加密,包括操作系统。

  2. 过滤器驱动程序或文件系统加密:您可以编写自己的过滤器驱动程序或文件系统驱动程序,以便在将文件写入磁盘时选择性和透明地加密和解密文件。大多数以业务为目标的加密解决方案都提供这种功能。 Microsoft 有自己的解决方案,形式为Encrypting File System。这样做的好处是它与操作系统更好地集成,加密的文件和文件夹在所有其他应用程序中看起来就像普通文件。 TrueCrypt 是另一个进行这种加密的程序,它是开源的,所以你可能想看看它。

  3. 应用程序级别加密:您还可以在应用程序级别加密文件,就像我想调用的那样。如果您不编写自己的过滤器驱动程序,您将无法超越此级别。这意味着您加密文件的方式与使用 WinZip 压缩文件的方式类似。其他应用程序可以看到加密文件作为不同格式的文件,而不是原始格式。本质上,它与使用 WinZip/WinRAR 压缩文件没有太大区别,只是不是压缩而是加密它。如果你用 WinZip 压缩一个文件夹,它仍然会被压缩成一个文件。如果您要在此级别进行加密,则与加密相同。您可以为 Windows 资源管理器编写 shell 扩展,使其“看起来”像一个文件夹,但本质上它仍然是一个文件,您将无法从另一个应用程序“另存为..”到该文件夹​​中。例如,如果您双击该文件,您可能还需要提供一个用于浏览文件夹的 GUI。

我假设您正在寻找将在应用程序级别进行加密的应用程序。在这种情况下,您应该意识到我上面提到的这种方法的局限性。

至于你的问题:

  1. 您可以将文件夹加密到一个容器中,再想想 WinZip/WinRar,或者您可以将文件夹中的每个文件单独加密到单独的文件中。

  2. 对于密码/密钥的使用,我的建议是使用随机密钥来加密实际数据。然后,您使用从一个或多个密码派生的密钥在单独的密钥槽中加密此密钥。这将允许您为一个文件设置多个密​​码。至于算法,我推荐 AES-128,因为它是一种经过充分验证且速度非常快的算法。要使用 AES,您需要创建具有特定长度的密钥和 IV(每个 AES-128 128 位)。创建这些密钥的最佳方法是使用Rfc2898DeriveBytes 和用户输入的实际密码。不要忘记HMAC,您应该使用它来验证文件的实际解密是否正确。您可以使用 HMAC 仅验证随机密钥是否已正确解密,这意味着您无需对整个内容运行 HMAC。

  3. 为此,您需要编写一个 shell 扩展,但这只能帮助您到此为止。例如,您将无法将 word 中的文件保存到加密文件夹中,因为这实际上只是加密文件的容器格式。

  4. 我建议您让用户自行创建文件备份。任何被删除的文件也应该是wiped securely,因为简单的删除不足以从文件系统中删除文件的所有痕迹。

【讨论】:

  • 别担心!我在一家开发这种商业解决方案的公司工作,而且把它做好绝对不是一件容易的事。祝你的项目好运。
  • 非常感谢您提供更多信息!我知道这绝对不是微不足道的。我希望将来能再次见到你,回答我在这个领域一定会遇到的更多问题。 ;)
【解决方案2】:
  1. 文件夹只是文件的集合。就您的应用程序而言,它可以只加密文件夹的内容。
  2. 您应该使用密码来派生密钥。在 .NET 中,您可以使用 Rfc2898DeriveBytes 做到这一点。这意味着您甚至没有存储密钥。密码的关键。如果可以避免,切勿自己保留钥匙。这样,攻击者的唯一选择就是蛮力;逆向工程不会产生任何有用的东西。
  3. 您可能必须写一个shell extension 才能做到这一点。那是完全不同的主题。 (我希望您对 COM Interop / PInvoke 感到满意)。
  4. 这一切都取决于您想要多少“验证”。例如,您可以计算原始文件的 SHA-256 哈希值;加密它;然后解密它;散列解密文件;并确保哈希匹配。诀窍是将所有这些作为原子操作来完成。您可能还希望存储未加密文件的 SHA-256(即使在删除未加密内容之后),以便以后解密时;您可以验证它是否正确完成。在这种情况下,您将哈希用作校验和。

【讨论】:

  • 你不想在 .NET 中编写 shell 扩展。
  • @ChrisV:如果 shell 扩展很困难,你还有什么建议来做我在问题 3 中提出的建议吗?
  • @ChrisV 在 .NET 4.0 中编写 Shell 扩展很好。请参阅 In-Process Side-by-SideWriting Windows Shell Extension with .NET Framework 4 (C#, VB.NET) - Part 1: Context Menu Handler 这修复了 CLR 加载时的竞争条件
  • .NET 4.0 对于 shell 扩展仍然不安全。如果 .NET 1.1 应用程序出于某种原因(例如,因为一个通用文件对话框)尝试激活它,新框架将拒绝加载。只有 2.0(包括 3.x)和 4.0 运行时可以共存。此外,来自您链接的博客:“因此,Microsoft 将不支持托管 shell 扩展,并建议不要编写它们。”
【解决方案3】:
  1. 是和不是。文件系统有加密标志,可以应用于文件夹。这很重要,因为在该文件夹中创建的新文件将被自动加密。但是文件夹本身没有加密。

  2. 我不太明白...如果它像 TrueCrypt 一样工作,那是个好主意。

  3. 哪个密码?无论如何,如果它是您的加密方法,那么您必须深入研究 Windows Shell API 和对象,我不太确定 .NET 是否可以进行这种扩展(我想我在某处读到它不是,实际上它会由于某种原因我忘记了失败)

  4. 我不明白为什么解密会失败。显然任何事情都可能发生故障,包括硬盘驱动器,但随后每个文件都可能发生故障,您无法避免这种情况。

【讨论】:

  • 我无意粗鲁,感谢您的帮助,但如果已经有答案,您应该阅读它们,看看您的帖子是否会添加他们错过的内容,或者它只会使答案部分变得混乱。在这种情况下,它很混乱。
  • 好吧,我没有看到这里的任何答案与上面的任何答案重叠,除了可能是第三个,但在这里扩展得更多(有人提到文件夹标志,有人提到 TrueCrtypt - 实际上上面的答案是对面的)。如果您发现上面的答案已经足够了,那么给这个减号是个坏主意,但它会带走您的分数,所以如果您觉得舒服就可以了。
  • #2 你只是说你不明白,#3 你问的是哪个密码,虽然你的答案是正确的(但是在之前的答案中已经提到过),对于#4,你绕过了这个问题,谈到了为什么解密可能会失败,但没有回答这个问题。道歉,但你没有帮助回答我的问题或给我任何额外的有用信息。对于将来可能需要类似帮助的阅读此答案的人,我不希望他们被误导。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-11-08
  • 1970-01-01
  • 2010-10-10
  • 2019-04-12
  • 2014-04-11
  • 1970-01-01
相关资源
最近更新 更多