[RESOLVED] how can i encrypt a file?

[Eri523]

encryption:
String ^strInputFileName ="peter.txt"; 
String ^strOutputFileName = "hungry.txt";

decryption:
String ^  strInputFileName = "hungry.txt";
String ^strOutputFileName ="peter.txt"; 

reencryption:
String ^strInputFileName =  "peter.txt";;
String ^strOutputFileName = "hungry.txt";

This looks correct, provided that the password parameter is the same for all three calls and the mode parameter is set to true, false, true, in that sequence.

this doesnt work how i would like it too because the hungry file remains in plain text which makes it visible to other apps.

What do you mean by "remains unencrypted"? Based on the sequence described above, there never should be an unencrypted file named hungry.txt at all.

if i put a new filename in the outputfile for decryption , when that file is edited it doesnt get updated when re-encrypted.

Maybe the file you re-encrypt actually isn't the file that you have edited?

sorry am abit confused do you know how i can get it to run how i would like?

Well, unfortunately your description of what's going on isn't really clear. Some more information might be helpful, maybe with code.

Note that if you use the user's password as the password parameter to Crypt(), you need an individual encrypted file for each user, even if the original plaintext file should be the same for all users. That's because the contents of the file the encryption results in of course depends on the password.

[katy_price]

to avoid the problem of the file been left in a readable state, after encryption and re-encryption i delete the monk file and it seems to do the trick. i used system("del monk.txt"); to delete the file, i dont actually like using the system funtion because i can see the cmd window. when deleting the file it just flashes on and off but when i call the file using it, it actually stays open until i close the file, which is annoying, but i couldnt find any other function that would do what i wanted and was easy to implement.

[Eri523]

with this order the monk file is always readable. without running the program i can open and read the monk file through windows explorer. [...] i have debugged the program at each stage and it is always readable. the problem is the file does not get destroyed after it is encrypted and the output is sent to another file. [...]

all users will use the same password paramater and the same file.

Ah, now I've got what your problem was. If all users share the same file (and the same versin of that file) and all use the same encryption key, you can simply "ping pong" between the encrypted and the plaintext version of the file. I.e. always delete the plaintext file after encryption. And there would be no need to delete the encrypted file since it is no security risk and will be overwritten the next time you encrypt anyway.

The shared key actually can raise some security concenrns if it is hard-coded inside your app, but as protecting a shared key can really complicate things I think we should put aside the concerns for now, for the sake of simplicity.

so when the file is encrypted and if the plain text file gets destroyed there would be no file with text to encrypt the next time round (e.g another user enrolls). the output filestream would just create a new file with the same name but this would have no text to encrypt.

I don't really get what you mean by this, however.

to avoid the problem of the file been left in a readable state, after encryption and re-encryption i delete the monk file and it seems to do the trick.

Yes, indeed. But just FYI I'd like to mention that deleted files can be restored under certain circumstances. While normal users usually aren't able to do that, any apprentice hacker will likely have a program for this task. Fixing this security hole would require some sort of secure deletion, which can be quite tricky, as this thread in the Non-VC++ forum illustrates. This is, however, non-managed stuff. I just wanted to point you there to scare you a bit. But like with the hard-coded key, I think we should put aside these security concerns as well for now.

i used system("del monk.txt"); to delete the file, i dont actually like using the system funtion because i can see the cmd window.

Yes, I consider using system() calls painful as well, and for the deletion I have found an alternative that's even clean .NET style: the IO::File::Delete() method.

when deleting the file it just flashes on and off but when i call the file using it, it actually stays open until i close the file, which is annoying, but i couldnt find any other function that would do what i wanted and was easy to implement.

It took some time but I've even found a .NET alternative for this as well: the Diagnostics::Process class! It took some time to find it because I didn't expect to find it in the System::Diagnostics namespace. The class can do a lot of fancy things most of which we dont't even need here, and a significant part of them indeed is related to diagnostics, which obviously is the reason why they put it there.

Using this class, you can replace this:

  system("monk.txt");

by this:

  Diagnostics::Process ^proc = Diagnostics::Process::Start("monk.txt");
  Diagnostics::Debug::Assert(proc != nullptr, "Process::Start() returned nullptr");
  proc->WaitForExit();
  proc->Close();

You can look up the methods used here on MSDN, starting from the link I gave you above, to understand what's going on here. (It's really a bunch of stuff to read, however.)

The Assert() is there to catch the case when the call to Process::Start() didn't actually start a new process to open the file, but instead delegated opening the file to an instance of the associated app that's already running. This can't actually happen as long as you're opening .txt files and theye associated to Notepad, but it's easily possible if you want to open .doc files with Word, for instance.

This sequence of comands is blocking (as is the system() call) and will render your app irresponsive as long as the target file is opened, but if you, as I understood the description of your app, will have either closed or hidden all GUI elements when this is called, the user can't interact with your app anyway at this point. So, the blocking nature of that command sequence isn't much of a pain and will rather simplify things, so a worker thread is dispensable for instance.

[katy_price]

wow the Diagnostics::Process stuff is amazing, thanks alot. i have learned alot of things, thanks for all your help. i wish i could give you a gift lol .

[Eri523]

[...] thanks for all your help.

You're welcome.

i wish i could give you a gift lol .

How about some reputation points? I always appreciate them.

[katy_price]

hi sorry i have another question about the cryptographic transformations: i know you said that true is encrypt and false is decrypt depending on what the mode is set to. however how does the program know from the if statement which one to do, like is CreateEncryptor(); always equal to 1 so if i say mode = true it will perform encryption? and is CreateDecryptor(); always = to 0... is it possible to reverse it so decryptor is true? i'm just trying to work out why true is encryption and false is decryption

[Eri523]

You probably know already that the "en/decrypt while copying" operation always goes from the input file (first parameter) to the output file (second parameter) via the crypto transformer. The decision whether to encrypt or decrypt is taken in this piece of code:

  if (bMode)  // Encrypt
    cryptrans = cryptalg->CreateEncryptor();
  else  // Decrypt
    cryptrans = cryptalg->CreateDecryptor();

It creates either an encrypting or decrypting crypto transformer, depending on the value of bMode.

is it possible to reverse it so decryptor is true?

This is really simple: Exchange the if and the else branch. Or, which would require the least code changes, simply write !bMode instead of bMode. (Well, it would be a good idea to change the comments appropriately as well, otherwise it might get a bit confusing... )

i'm just trying to work out why true is encryption and false is decryption

This is essentially just because I wrote it that way. As shown above, it's no problem to change that.

[katy_price]

ok thanks i just wasn't sure whether the decrypt function had a 0 value as a default and the encyption was always 1 so would equal true. so basically i could do this - if bmode is true decrypt else encrypt. is it whatever is first in the if statment that determines if its true

[Eri523]

Right.

And if you'd like it extra fancy, you can define an enum like this:

public enum class CryptMode {Encrypt, Decrypt};

Then you could call Crypt() like this:

bStatus = Crypt("input.dat", "output.dat", strPassword, CryptMode::Encrypt);

Of course that would require to change the last parameter of Crypt() to that enum type and to modify the relevant if statement to something like this:

  if (cmMode == CryptMode::Encrypt)  // Encrypt
    cryptrans = cryptalg->CreateEncryptor();
  else  // Decrypt
    cryptrans = cryptalg->CreateDecryptor();

[katy_price]

thanks

[katy_price]

you know the block size 512, will it be padded if the data is less than the size of the block. or does that only happen if it is related to the crypto algorithm?

[Eri523]

To be honest, I simply don't know whether, in case of an incomplete read operation, the remaining bytes of the buffer are padded, left in their previous state or simply contain garbage. And it's downright irrelevant: cryptstream->Read() returns the number of bytes that actually have been read and that I store in nBytesRead. And this is the value I use to specify the number of bytes to write in the call to fOutput->Write(), not the buffer size. This simple mechanism ensures that any excess bytes in the buffer are ignored in the write operation, so it doesn't matter what they contain.

[katy_price]

To be honest, I simply don't know whether, in case of an incomplete read operation, the remaining bytes of the buffer are padded, left in their previous state or simply contain garbage. And it's downright irrelevant: cryptstream->Read() returns the number of bytes that actually have been read and that I store in nBytesRead. And this is the value I use to specify the number of bytes to write in the call to fOutput->Write(), not the buffer size. This simple mechanism ensures that any excess bytes in the buffer are ignored in the write operation, so it doesn't matter what they contain.

so is it safe to say 512 bytes of data is encrypted at a time whilst the block size equals the data in the input file. When the data is smaller than the block size the last convertion and copy is made to the output file?

[Eri523]

so is it safe to say 512 bytes of data is encrypted at a time whilst the block size equals the data in the input file. When the data is smaller than the block size the last convertion and copy is made to the output file?

My code takes care of incomplete blocks at the end (or, maybe to put it simpler, doesn't need to care about that the way it's written) and the crypto transformer essentially does the same in its code we both don't know, as I've already explained in an earlier post.

So why worry about that at all?

[katy_price]

My code tekes care of incomplete blocks at the end (or, maybe to put it simpler, doesn't need to care about that the way it's written) and the crypto transformer essentially does the same in its code we both don't know, as I've already explained in an earlier post.

So why worry about that at all?

its because i have to explain in my write up whats happening and how its happening and i don't want to get it wrong. i just needed to know the copy process so i can write it. so it reads, encrypts/ decrypts data in the input file and copies data 512 bytes at a time to the output file, when the data is less than the buffersize thats essentially the last read and copy right?