Shred Program

[Lv0f92yv]

I have written a simple program to 'shred' a file - the same idea as is provided in linux via the 'shred' command. I realize my program is not as complex or robust, but I am looking for some feedback regarding it's effectiveness.

For those interested or concerned, I am seeking to write a program that will effectively 'shred' documents such as resumes, financial and other personal information that I do not want others to obtain should my hard drive be recovered by a third party.

Any feedback, positive and negative is greatly appreciated. Here is my shred function:

void shred( string fname, int size, int times, bool zpad )
{
	ofstream shredfile;
	shredfile.open( fname.c_str(), ios::out | ios::binary | ios::ate );

	if ( shredfile.is_open() )
	{
		cout << "Shredding...";
		for ( int i = 0; i < times; i++ )
		{
			int at = 0;
			shredfile.seekp( 0 );
			//shred it
			while ( at < size )
			{
				srand ( time(NULL) + at + i ); //will be diff at each pass, but uniform pattern
				int randBit = rand();
				shredfile.put( randBit );
				at++;
			}
		}
		if ( zpad )
		{
			cout << "Padding...";
			NL;
			int at = 0;
			shredfile.seekp( 0 );
			while ( at < size )
			{
				shredfile.put(0);
				at++;
			}
			
			cout << "Shredding complete.";
			shredfile.close();
		}
	} //endifopen
	else cout << "Error shredding file: " << fname;

Note that NL is defined as a constant: cout << "\n";

[imi]

For very very basics, put a flush after the while loop or else your OS will most probably only write one time to the hard drive, regardless of the specified "times" parameter (write-cache).

But to be honest: You won't be secure against anything that uses a bit more than just the random "undelete.exe" download. (And probably even not against this undelete.exe). Main reason is, that your file is most probably stored multiple time in different stages of its existence all over the free space of your hard drive. There is no reason the hard drive driver will use the same location on the drive for every write attempt you make and many driver are even trying to spread the write operation if possible to make the drive live longer. This is especially true for flash-drives like USB-sticks.

Speaking of flash... it has another huge problem for sensitive data: Flash has an extremely good memory effect and by writing just a couple of random data over flash will still enable attacker with good equipment (means: who can read the analog signal on the stick) to get a good grip of most of the former bits in your file.

You *could* write the opposite value of what is written there 2 or 3 times before writing random datat to increase the forgetfullness, but I would strongly recommend against it. The reason is: hard drives (and larger USB-sticks) uses a flash-memory-cache with the worst case of the bad "memory" problems mentioned above, so every time you read some sensitive data from an unencrypted source, it makes the problem worse.


About encrypted file systems: For "normal" file systems, they are usually constructed in a way that you can reconstruct parts of the file even if you lost some other parts. Imagine you have just a plain text file and the first 3 bytes become successfully unreadable. This usually won't affect all the other bytes in the file, so if the first three bytes were unimportant anyway, your attacker can still read all interesting information.

So you want to use an encrypted file system to start with. Encrypted file systems are usually build in a way that you have to recover almost all bits of a file perfectly (plus know the encryption key) before you can access *any* of the file's content. Every bit not reconstructed should double the amount of calculation an attacker needs to finally read any part of the file.


My bottom paragraph: If you target very simple undelete-tools that don't pattern-scan your free disk blocks and if you don't care about people using special driver or even open your hard drive then you can try to pimp your code. Else: Use a good encrypted file system and use the provided safe-delete function from the tools that come with the file system (if there is no such function, you don't have a good encrypted file system ;).

Ciao, Imi.

[Lv0f92yv]

Thanks for the informative post.

Currently, I have an external drive with an encrypted file system. I don't know what algorithm/key size it uses, but it was provided by Fedora 12. Is this type of file system really any more secure than typical unencrypted systems? Or are there easy ways for attackers to get around this?

Also, for an encrypted system, how does it keep track of all the different write operations for a given file? (You mentioned drives usually don't write to the same spot twice for various reasons).

[imi]

Currently, I have an external drive with an encrypted file system. I don't know what algorithm/key size it uses, but it was provided by Fedora 12. Is this type of file system really any more secure than typical unencrypted systems? Or are there easy ways for attackers to get around this?

As I said, an encrypted file system is usually much harder to circumvent when it comes to undelete files without knowing the encryption key. If you don't know any key and don't have to enter any password at mount time, then the key is probably stored somewhere else on an unencrypted hard drive and this makes the encryption at maximum as secure as the encryption key's protection. (And since you read the encryption key all the time from the hard drive spot often, you can bet that it's stamped all over the hard-drives cache).

But to be really sure, you should ask at a Fedora - forum, the forum/mailing list of your encryption file system's people (probably dm-crypt) or at least a linux forum. They know better. ;-)


BTW: "More secure" also depends a lot on which attacker we are speaking of. If an attacker gets access to your computer while it is running or when it was just shut down or when he has some cryogenics with him, then you are probably not better off with an encrypted file system. However, it helps wonders against your neighbour undelete.exe-downloader you are going to sell your hard drive to ;-)

Another example: If you want to protect against people who have access to this particular hard-drive only (say.. you fear theft of your USB-stick), then you don't need to encrypt your /tmp and your swap partition. If you want to protect against Mafia-similar people storming your house and robbing you of all electronics, you WANT to encrypt the whole hard drive and switch off the computer as soon as you finished working.

Also, for an encrypted system, how does it keep track of all the different write operations for a given file? (You mentioned drives usually don't write to the same spot twice for various reasons).

They don't have to, because they are not writing readable data to the hard drive.

The hard disk driver takes care that the file system gets the same data back as it wrote last time, but it doesn't guarantee that data is overwritten only because you write on the same logical node. (There are drivers who do this, but some don't. Even those who do won't guarantee anything about cache memory or take care of other logical nodes your file system used before for older versions of the file). Encrypted file systems just don't care whether the hard drive spread information all over the place or into its cache. It's all encrypted data anyway.

Ciao, Imi.

[Lv0f92yv]

Very interesting - I have heard about this cryogenics stuff before. It is possible to lower the temperature of the memory set enough to preserve the current within it, pop it out of your PC (not necessarily in that order), and load it on something that can read the memory back?

Don't think I need to worry about that, but it sounds fascinating. I suppose this is where hardware encryption comes in?

[imi]

Very interesting - I have heard about this cryogenics stuff before.

Well, yea.. well.. "cryogenics" sounds very esoteric and may give a feeling of Ghostbuster-similar looking guys with $100.000 expensive equipment and a stone-frozen laptop afterwards. Actually it just means a 7 dollar bottle of cooling spray from the next Walmart ;-). You only need to cool it down to about -20°C (-4°F) or so. RAM can take this, so nothing is permanently broken.

For example, I've been told that here in Germany, Police is equiped with cyrogenics routinely when doing house searches.

It is possible to lower the temperature of the memory set enough to preserve the current within it, pop it out of your PC (not necessarily in that order), and load it on something that can read the memory back?

Yes. For more info, watch this: http://citp.princeton.edu/memory/

Ciao, Imi.

[Lv0f92yv]

Thanks for the article, I read it and watched the video. It seems the root of the problem is that memory is not 'reset' or 'defaulted' to anything - which makes sense. To change this behavior, is there a conceivable way to write a program to manually (at your choosing), 'scrub' the memory? I understand the operating system uses RAM all the time when it is running, and therefore that memory can't be modified without corrupting the OS, but is an approach like this feasible?

I'm just interested now since I didn't realize attacks could work like this.

[imi]

the root of the problem is that memory is not 'reset' or 'defaulted' to anything

Well, I wouldn't count this as the "root of the problem". Actually, resetting memory is just one solution for the real problem ;-) (e.g. using encrypted memory and some hardware key storage is another). For me, the root lies somewhere else.

When you design a security system, you have to make assumptions what an attacker can do and what he can't. (There is no security against an omnipotent, god-like attacker that can read minds, examine all atoms in the world, even break (quantum) physic laws etc..). So in fact, you always have to make assumptions.

When designing hard drive encryption, the designer made the assumption, that RAM can not be read. If you now negate this assumption, the system doesn't provide security anymore. Nothing to be surprised at. So why is this still a "problem" and why are we surprised now? Because the designers may not have been aware of their assumptions. They probably didn't write it clearly on their advertisment: "Warning: This doesn't work if someone owns a $7 bottle of cyrogenics."

So the root of the problem lies in the fact, that the designer didn't thought of all assumptions they made and that their attacker model just descirbed the wrong attacker (more specific: a too weak attacker).

is there a conceivable way to write a program to manually (at your choosing), 'scrub' the memory?

I guess its just better if you enable things like "Forget password at ScreenSaver-lock" in TrueCrypt. For linux and dm-crypt, you probably would have to write some suspend-script. IDK how and where, ask in their forums ;-).

You can also use GnuPG in -c mode (symmetric on-the-fly encryption/decryption). IIRC, it erease the memory after usage.


Hey, we found a nice circle back to the original topic, but on a different layer: Now we are at "How to erase sensitive information in the RAM?" :-D

Ciao, Imi.

[Lv0f92yv]

You should teach somewhere.

I will have to look into those items listed above, if for nothing else just to understand how they work. I will be doing some googling tonight :]

Thanks again for the enlightening posts.