在 C#.NET 中安全删除文件
在我正在做的一个项目中，我想为用户提供“安全”删除文件的选项 - 例如，用随机位或 0 覆盖它。在 C#.NET 中是否有一种简单的方法可以做到这一点？效果如何？
In a project I am doing I want to give users the option of 'securely' deleting a file - as in, overwriting it with random bits or 0's. Is there an easy-ish way of doing this in C#.NET? And how effective would it be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以调用 sysinternals SDelete 来为您执行此操作。这使用碎片整理 API 来处理所有这些棘手的边缘情况。
如果您想以更方便的形式重新打包该逻辑，请参阅 API 这里。
You could invoke sysinternals SDelete to do this for you. This uses the defragmentation API to handle all those tricky edge cases.
If you want to repackage that logic in a more convenient form, the API is described here.
您无法安全地删除日志文件系统上的文件。唯一仍在大量使用的非日志系统是 fat32。在任何其他系统上，安全删除的唯一方法是粉碎整个硬盘驱动器。
编辑
安全删除不起作用的原因是，用于覆盖文件的数据可能不会存储在与其覆盖的数据相同的位置。
微软似乎确实提供了一个安全的删除工具，但它似乎不是你可以用来替代的东西。
除了粉碎磁盘之外，防止已删除文件恢复的唯一好方法是在将文件写入磁盘之前对其进行加密。
You can't securely delete a file on a journaling filesystem. The only non-journaling system still in heavy use is fat32. On any other system, the only way to securely delete is to shred the entire hard drive.
EDIT
The reason secure delete doesn't work, is that that data used to overwrite a file might not be stored in the same location as the data it is overwriting.
It seems Microsoft does provide a secure delete tool, but it does not appear to be something that you can use as a drop in replacement.
The only good way to prevent deleted file recover, short of shredding the disk, would be to encrypt the file before it is written to disk.
这根本不安全。相反，您可能希望考虑加密等替代解决方案。
一种解决方案是加密数据文件的内容。每次更新文件时都会使用一个新密钥。当您想要“安全删除”数据时，只需“丢失”加密密钥并删除文件即可。该文件仍然物理上位于磁盘上，但如果没有加密密钥，恢复将是不可能的。
以下是关于为什么“安全”覆盖文件安全性较差的更详细解释：
如果没有低级工具（.net 运行时之外），您将无法访问物理磁盘位置。以 NTFS 上的文件流为例，当您“打开文件进行写访问”时，您无法保证“更新的”副本（在本例中为随机 101010 版本）将存储在同一位置（从而覆盖原始文件）。事实上，大多数情况下会发生这种情况：
1) 文件 x.dat 存储在簇 8493489 处
2) 打开文件 x.dat 进行写访问。操作系统返回给您的只是一个指向文件流的指针，该文件流不仅由操作系统抽象，还由底层文件系统和设备驱动程序（例如硬件 RAID）以及有时物理磁盘本身（SSD）抽象。您用随机 1 & 更新文件的内容。 0s 并关闭文件流。
3) 操作系统可能（并且很可能）将新文件写入另一个集群（例如集群 4384939）。然后，它只会更新 MFT，指示文件 x 现在存储在 4384939 处。
对于最终用户来说，看起来只存在该文件的一份副本，并且现在其中包含随机数据，但原始数据仍然存在于磁盘上。
相反，您应该考虑在每次保存文件时使用不同的密钥加密文件的内容。当用户想要“删除”文件时删除密钥和文件。物理文件可能会保留，但如果没有加密密钥，恢复将是不可能的。
It wouldn't be secure at all. Instead you may wish to look at alternative solutions like encryption.
One solution would be to encrypt the contents of the data file. A new key would be used each time the file is updated. When you want to "securely delete" the data simply "lose" the encryption key and delete the file. The file will still be on the disk physically but without the encryption key recovery would be impossible.
Here is more detailed explanation as to why "secure" overwrites of files is poor security:
Without a low level tool (outside of .net runtime) you have no access to the physical disk location. Take a filestream on NTFS, when you "open a file for write access" you have no guarantee that the "updated" copy (in this case random 101010 version) will be stored in the same place (thus overwriting the original file). In fact most of the time this is what happens:
1) File x.dat is stored starting at cluster 8493489
2) You open file x.dat for write access. What is returned to you by the OS is merely a pointer to the file stream abstracted by not just the OS but the underlying file system and device drivers (hardware RAID for example) and sometimes the physical disk itself (SSD). You update the contents of the file with random 1 & 0s and close the filestream.
3) The OS likely may (and likely will) write the new file to another cluster (say cluster 4384939). It will then merely update the MFT indicating file x is now stored at 4384939.
To the end user it looks like only one copy of the file exists and it now has random data in it however the original data still exists on the disk.
Instead you should consider encrypting the contents of the file with a different key each time file is saved. When the user wants the file "deleted" delete the key and file. The physical file may remain but without encryption key recovery would be impossible.
我首先尝试简单地打开该文件并覆盖其内容，就像我通常所做的那样。在 C# 中相当简单，我什至懒得写它。但我不知道这有多安全。一方面，我非常确定它不适用于使用复杂算法提供磨损均衡的闪存驱动器和 SSD。我不知道那里有什么用，也许需要在驱动程序级别上完成，也许根本不可能。在普通驱动器上我只是不知道 Windows 会做什么。也许它也会保留旧数据。
I'd first try simply to open the file and overwrite its contents as I would normally do it. Pretty trivial in C#, I won't even bother to write it. However I don't know how secure that would be. For one thing, I'm quite certain it would not work on flash drives and SSD's that use sophisticated algorithms to provide wear leveling. I don't know what would work there, perhaps it would need to be done on driver level, perhaps it would be impossible at all. On normal drives I just don't know what Windows would do. Perhaps it would retain old data as well.
古特曼擦除实现
Gutmann erasing implementation