Printable View
Hello everybody
I recently published a thread concerning two questions, but got answered for only one of them, so here Im asking the second one again, hope you could help me..
How can I detect an unexpected termination of a program?
My program encrypts files, how can I possibly roll back the changes that were made on the file if he was not fully encrypted / decrypted (and therefore will never go back to it's original state)?
thanks
Well, you can't really.
Unexpected might mean power failure, disk failure - one machine I serviced was under a water leak (afterwards it was nicknamed the sparkler).
You can read up on exceptions, but they can't catch all operating system errors.
Some operating systems have their own exceptions features and you can often arrange to catch those something like exceptions, but that still won't tell if if the power suddenly cutoff or that the processor fried.
What you can do is process to a second output file such that there's a status code written as the last step. If that status code doesn't appear, the work wasn't completed. One typical approach is to write to a file with a recognizable working extension (sometimes .$$$ or similar), and rename only after successful completion.
Ok, so I can write a file with a unique extension or a registry value everytime a file starts to encrypt / decrypt and change it once it's done, therefore I'll know whats the status on the next program run.. right?
By the way I didn't mean unexpected to the extent of power cuts or massive hardware failiure..
How does industrial encryption programs handle this?
If the program does not leave the source file unchanged and creates a new file which is the encrypted, they have to do something if the program shuts down (even by ctrl alt del) while the encryption is running..
no?
thanks
I know, but the fact is that really is part of unexpected termination - it's a reasonable scenario to encounter which ought to be "handled" in a logical way, which is why I injected the point.Quote:
By the way I didn't mean unexpected to the extent of power cuts or massive hardware failiure..
True, there are messages sent to Windows applications during shutdown (ctrl-alt-del in Windows brings up a task manager dialogs).
In other environments it is similar. You might be thinking of MSDOS, which is not considered secure or industrial, so any use of it is a "force fit" of this concept. However, there are interrupts representing these concepts that can be intercepted - none of them are entirely reliable.
Yeah sure, understood why you brought up the power cuts and the rest..
Just to be sure I understand, you are saying that the world's leading programs which handle files, when shut down abnormally could damage the file they were handeling and there is no good way to overcome this?
You mean like the UNIX operating system? Turn off a UNIX machine abruptedly, and then get ready to cry when you turn the machine back on.Quote:
Originally Posted by Igeru
Regards,
Paul McKenzie
lol I didnt mean UNIX.. but why?
But whether you mean UNIX or not illustrates the general point.Quote:
Originally Posted by Igeru
If the program, regardless of what it is, is writing or changing a file at the time the machine goes down, you're out of luck, unless the program stores backups before doing the operation, using techniques like this:
http://en.wikipedia.org/wiki/Snapshot_(computer_storage)
The UNIX operating system is just an example of a program (the OS is the program), that will more than likely corrupt the file system if turned off without the proper shutdown. Having said that, most operating systems work this way.
Regards,
Paul McKenzie
Either the problem is obviously simple or I don't understand something....
Well, You have a file (say 'source.txt') which you want to encrypt. Create a file witch the name say '~source.txt.my_scrambler_tmp' and send encrypted data to it.
When you program gets to the end of 'source.txt', securely erase source.txt, then rename ~source.txt.my_scrambler_tmp into 'source.txt'.
If you (or your program/its user) see file with extension '.my_scrambler_tmp' it means encryption ended unsuccessfully and 'source.txt' is still not encrypted. White this in Troubleshoot section of user documentation.
That's ok that you need some free space on the disk(equal to 'source.txt' size)
You have it right.
Specifically with the file system, Windows registry, other control files (like /etc/rc in Unix), the process you outline is the only general approach which fits the circumstances.
There may be fault tolerant versions of operating systems, hardware and file systems which can help somewhat, but generally computer systems have too many potential sources of failure to rely upon them.
Honestly, the more you know how things work in a computer, the more amazed one is that they work at all :)
The notion of "in place editing" of files is known to be flawed (reasons already discussed), and the theory applies similarly to exception safety of copying objects in C++.
You could also encrypt your file cluster by cluster (by 4096B by default on NTFS). NTFS grants that all read/write operations are either successful of recoverable, but you still need to save the number on the last cluster successfully proceeded.
Saying this I feel myself at fault. I would strictly recommend you to do this in a way I've described in my post #9. As cluster size could vary, some folks still use FAT, and even Linux file systems on Windows via third party drivers.
But what is you reason to encrypt/decrypt in a single file?
what?Quote:
Originally Posted by andrey_zh
Why do you want to encrypt your file and write encrypted data over the original?
Some modern file systems provide encryption on file system level (i.e. NTFS, EXT3)
Sorry, I didn't understand why not to do what I do.. please explain..
thanks
I believe andrey_zh is pointing out that the service of encrypting a file may be available from the operating system, making the act of encoding within the application seem like extra work.
My own reaction is based on experimental work done a few years ago for a security firm. The encryption service in Windows (all versions from NT4 though Vista) is implemented in such a way that a nefarious utility can be used to "blank out" the administrator password, permitting access to the operating system and automatic decryption of those files encrypted by the operating system. Based on this research work, I can safely conclude the OS feature in Windows is all but cosmetics. I can now invade any system in about 3 minutes and copy all such files.
So, Igeru, the client for which I did this research agrees that encryption of files by applications is most pertinent.
I've talked about some different things:
The 1st one is explained by JVene. You could use OS services.
By the way, I have a question to JVene: Are you sure about XP and Vista? It seems, XP has some improvement in it's security system( NTFS5 vs NTFS4 on Win2K).
To Igeru: what encryption algorithm are you using? I've read some of your older threads and pointed that you read your file byte after byte. It seems to be not the best method, read file by larger chunks and naturally use a standard cipher. Look at some publicly available encryption algorithms. Also have a look at this: http://www.cryptopp.com/
If you're implementing a kind of Caesar's cipher, it still would be better to use an OS services.
The 2nd is the following:
You are going to store some data in encrypted file. How are you going to use it? Are you going to store some settings there or you are writing a scrambling utility for user's files?
andrey_zh,
Yes, I'm sure. The 'attack' is performed using a utility, which can be placed on a USB key if the machine boots from the key, or CD - the 'blanking' of the administrator password is performed from outside the operating system, after which XP and Vista actually perform as though the administrator has signed in, all files are available.
Tests show Windows 7 is similarly vulnerable, though the specifics differ slightly.
Put another way, from a simple theoretical viewpoint, if the keys for decrypting a file are owned and controlled by the operating system, then any attack that gains control of that OS open these files to decryption, and no OS is more "researched" for vulnerabilities than the Windows family.
On the other hand, if the encryption approach involved large keys stored external to the OS (a USB key, for example), then attacking the OS itself is of no value toward decrypting the files.
Well actually, although my knowledge in c++ programming (and programming in general- only a minor hobby of mine) isn't much (as you both clearly see), I have a solid background regarding encryption, mostly Mathematical, and a few month of reserch I've done, so in this sense I ok :)
I know I published many questions lately, where I din't give the whole picture each time (dropped out the non relevant stuff to the programming itself), but thanks anyway for your advice, by the way Im not encrypting byte by byte :) and using a uniqe algorithm, trying to combine some encryption algorithms, some one-way functions, hash functions, salt data, cipher-blocks encryption and purhaps adding some elliptic curves to the whole deal..
But in the programming level you are all helping me so much, so thanks!
andrey_zh, to your question, Im scrambling the file's bits and not saving any new data regarding the encryption procces to the file (although Im cheking a good way to salt the file, and maybe when I'll get to the ecc this thing will change)..
JVene, after you did the research for the company, you both agreed that the OS encryption utility is NOT enough, right? the independent encryption softwares are crucial... right?
cheers
It's surprising how many consumers aren't at all conscious of the nature of encrypting data in the first place.Quote:
...after you did the research for the company, you both agreed that the OS encryption utility is NOT enough, right? the independent encryption softwares are crucial... right?
For those even aware, the consumer thinks the OS encryption feature is sufficient, as long as their password is safe.
If the consumer can be sufficiently educated on this point, or if you find a consumer that is, then yes, they'll easily realize the encryption feature within the OS is nearly useless.
Not just from the standpoint that it is not secure, but if the OS itself gets trashed, they may never be able to recover the encrypted data stored by the OS.