Hello All,

I have struck in a problem can any one give the solution....

I have a abc.txt file ,I am using AES algorithm to encrypt this file ...
This algorithm takes the input file and output file as arguments...

Ex if i give abc.txt as input ,the output is abc.txt.enc.
where abc.txt.enc is an encrypted file ..

But the problem is that when I give input file i.e., txt file I want the txt content to be replaced with encrypted content in the same file ...

I mean to say the input file and output file should be the same...

Similarlly while decrypting .....

VedaAnuhttp://linuxquestions.cachefly.net/images/questions/images/smilies/newbie.gif

Hello All,

I have struck in a problem can any one give the solution....

I have a abc.txt file ,I am using AES algorithm to encrypt this file ...
This algorithm takes the input file and output file as arguments...

Ex if i give abc.txt as input ,the output is abc.txt.enc.
where abc.txt.enc is an encrypted file ..

But the problem is that when I give input file i.e., txt file I want the txt content to be replaced with encrypted content in the same file ...

I mean to say the input file and output file should be the same...

Similarlly while decrypting .....

Use Vim to encrypt the file. It will do exactly what you want.

You need to create a temporary file for the output (either direction) and then unlink the first and rename the temporary file at the end.

In principle, since (I think!) AES is a block cipher where the size of a decrypted block is the same as an encrypted block, you could read a block, en/decrypt it, "seek" backwards in the file by one block and overwrite the content before moving forward. Check the lseek or fseek man pages. But I wouldn't recommend this - if you fail midway, you will have corrupted the original, and you would also have to fiddle the length of the file somehow in the last block (see the truncate function).

HTH.

Use something like encfs (requires FUSE) if you never need to share the file in encrypted form.

Well, 1st you need to post your Q in only 1 thread.

edit: see above (post merge)

Also be aware if what you're trying to do is eliminate the plaintext from the hard drive completely, it's tough to reliably accomplish that. Using a temporary file and then unlinking the old one leaves the plaintext somewhere on the disk. Journaling filesystems or even swap space can retain the plaintext. Ways around that: encrypt your swap partition, only put plaintext files on encrypted filesystems (either a partition created with cryptsetup or perhaps just a filesystem that lives in a regular file mounted on a cryptoloop) or in a ramdisk (like /dev/shm), or use ext2 and the shred utility.

I have one more idea. create 'test.txt' with plain text, 'test.txt.enc' with encoded text.. Delete 'test.txt' and rename 'test.txt.enc' back to 'test.txt'. This logic will work for both windows and linux systems.

But I have one question, will this effect the peformance since I first delete and then rename the file. Will my application be slower.

One more doubt will the application be secure if you follow the above logic. Will the hacker have any chance to get the plain text??

Hi puffinman, the solution you have told works for linux what if my application is portable one(windows and linux)???

"encrypt your swap partition, only put plaintext files on encrypted filesystems (either a partition created with cryptsetup or perhaps just a filesystem that lives in a regular file mounted on a cryptoloop) or in a ramdisk (like /dev/shm), or use ext2 and the shred utility."

Please explain this. I'm unclear about this explanation. If possible with some code example.

Thanks,
Jacko

Strictly, yes. But in practice, deleting and renaming a file will happen in the blinking of an eye. It would only be an issue if you were trying to process (say) thousands of files per second in your application.

This was puffinman's point. As long as the plaintext is on the disk anywhere, it's hard to guarantee it's been deleted (in the sense of not being on the physical disk surface - obviously the file is deleted). The techniques he refers to are worth considering.

these two threads have been merged. please follow the rules you agreed to next time and don't post twice.