Reputation: 533
I'm writing an encryption program that will encrypt files.
I want the encrypted content will replace the original content so it can't be recovered by recovery programs (That is, using the same memory addresses as the original content).
Assume that the encrypted content has equal size as the original content.
I guess that File.renameTo()
will not do the trick since it's platform independent so it's somewhat unpredictable.
Forgive me for not posting my full code (duh!) but I use Buffered Input/OutputStream
to read/write the data.
Upvotes: 1
Views: 101
Reputation: 1016
In some cases (on some operating systems, on some filesystems, with some mount options) RandomAccessFile will let you do what you want to do. Also think about how to keep sensitive data out of the Java heap... for example, avoid using String
as part of the objects constructed from the unencrypted file, and later written to the encrypted file. However, in other cases what you're proposing is simply impossible. As stated in the manpage for GNU shred
,
CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:
- log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
- file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems
- file systems that make snapshots, such as Network Appliance’s NFS server
- file systems that cache in temporary locations, such as NFS version 3 clients
- compressed file systems
Upvotes: 2