left shift operator!!!!

is it possible to retrive the msg back when we left shift the whole set of char of a file with some integer of range [255 to 0 in a for loop)....when i decrypt the msg it gave a mismatch in total char count.the plain txt has 5000 char where the same txt after left shift it gave only 3000 char..

wat is the reason...

theblackhat

Do I understand this correctly? You have a character set and you want to shift (like, encrypt) the characters of that file? You have 0-255 possible values, so you should shift them by an integer between 0-255, because if you add 256 to a character code, you get the same code, so it has no point. If so, then it should look something like this:

Code:

---


#define KEY 60  //anywhere from 0 to 255 - the number to add to each character code

int main(int argc,char *argv[])
{
    FILE *infile,*outfile;
    int i;
 
    if (*(argv+1))    //assume the 1st argument is the filename
    {
        if (infile = fopen(argv+1,"rb") //open the file in binary mode
        {
            char c;

            outfile = fopen("encrypted.txt","wb"); //create or rewrite the new, encrypted file
            while (c = fgetc(infile))
            {
                  fputc(c + KEY,outfile);   
            }
            fclose(outfile);
            fclose(infile);
        }
    }

    return 0;

}

---

Here you have a problem though. If you use different KEY's for different files, then you have no way knowing what KEY you used for a particular file.

So to retrieve the message back, you should either use the SAME key everywhere, or just write the key into the encrypted file as the first byte. For example, say your text file contains this: "secret".

That's 6 bytes. Now, when you write the encrypted file, you first write the KEY, as the first bit. If your key is 60, you'll write 60 as the first byte, which is '<' in a symbol notation. And, when shifting all of your file's characters forward by 60, you'll get the following file:

in decimal notation:

(60)(175)(161)(159)(174)(161)(176)

So, when later reading the file, you first read the key:

Code:

---

  fp = fopen("encrypted.txt","rb");
  key = fgetc(fp); //the first byte in the file

---

and then you'll read the file character by characer:

Code:

---

  contents[i] = fgetc(fp) - key; // fgetc(fp) - key gives the original character back
  i++;

---

Or something similar.. You get the idea.

EDITED TO ADD:

What you can't do, is use the left shift operator (the << operator) for this encryption. Why? Consider this:

Assume you have a character in the file: 'a'
in bit representation it's:

01100001

Now say you shift these bits to the left by four, eg you do:

Code:

---

a <<= 4; // or, a = a << 4;

---

What you actually do is this:

01100001 << 4 = 00010000

meaning, by shifting the bits left by 4, you fill the lower 4 bits with zeros and the higher 4 bits will become, what were the lower 4 bits, previously. But the previous higher 4 bits - '0110' will dissapear. Now you encrypted "01100001" into "00010000". But when later decrypting it, if you shift the bits back to left: 00010000 >> 4 = 00000001, because shifting bits right will simply bring zeros in from the right. You can and never will have any knowledge, of what the encrypted character used to be, since you can't know, what the previously left shifted 4 bits were.

So the only way you can do this "shifting"-encryption, is by adding or subtracting a certain integer value of 0-255 from each character in the file and remembering that value, which is the KEY for later decrypting the data as well.

Since that isn't worded well, I'll pharaphrase what I think you're trying to ask, and then answer:

Quote:

---

I have used left-shifting for my encryption method. When I right-shift back to decrypt, it doesn't give me the right answer. Why?

---

Right? That about it? Well, think about what is happening:

Here we have some bits:

00100100

Our "encryption" is shifting say 4 places to the left:

01000000

Now we shift back to "decrypt":

00000100

See the problem now?

You should go read the Bit shifting FAQ and then see if you can come up with some other kind of encryption. (Or, capture what is shifted off, and wrap it around manually for both encryption and decryption.)

I'll leave that as an exercise to the origional poster. (If you aren't the OP, you should too. ;))

Quzah.