Problems with Xor encryption

Hey guys, I'm trying to develop a Xor ecnryption function but I'm having some problems...

Here's what I've so far:

Code:

---

#include <stdio.h>

int main(int argc, char *argv[])
{
    char string[] = "This is a test!!!";
    char key[] = "123";

    XorEncrypt (&string, &key);
   
    printf("%s", string);
    getch();
    return 0;
}

int XorEncrypt (char *string, char *key)
{
    int cnt = 0, i, j, r, mod;
   
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6
   
    r = StringLen / KeyLen;
   
    for (i = 0; i < r; i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] = string[i*KeyLen + j] ^ key[j];
        }
    }
   
    mod = StringLen % KeyLen;
   
    if ( mod != 0)
    {
        for (i = 0; i < mod; i++)
        {
            string[-mod + i] = string[-mod + i] ^ key[i];
        }
    }
   
    return 0;
}

---

Output: eZZB↕ZB↕R◄FVBF↕!!


The function is not working tough, if I take that output and pass it again to the function I get this:

a♫test♀!!

I don't know if I made a mistake regarding pointers or if there's something wrong in the function itself... Please help =)

Quote:

---

Originally Posted by lala123

The function is not working tough, if I take that output and pass it again to the function I get this:

---

How are you passing the input back? Copy and paste? If so, the copy/paste is probably screwing up the values. I don't see anything wrong with the encryption code itself, so I think you are having some other issue here.

Also, you can't use printf() to display the result. The XOR encryption might have caused a byte to become zero, which in C indicates "end of string." You need to remember how long the string was before you encrypted it, and print exactly that many characters.

Printing encrypted data to a terminal is usually a bad idea, since it may contain control characters that confuse the terminal. I bet if you change your program to read/write its data from files instead of the console, it will suddenly work much better.

Thank you for your quick response buck. I tried doing as you said, but for some reason the text at the file remains unchanged...

Here's what I'm using:

Code:

---

#include <stdio.h>

int main(int argc, char *argv[])
{
    FILE *fp;
    long fSize;
    size_t result;
    char key[] = "123", *buffer;

    fp = fopen ("xor.txt", "rb+");
   
    if (fp == NULL)
      {fputs("File error",stderr); exit(1);}
     
    fseek (fp, 0, SEEK_END);
    fSize = ftell (fp);
    rewind (fp);
   
    buffer = (char*) malloc (sizeof(char)*fSize);
   
    if (buffer == NULL)
      {fputs ("Memory error",stderr); exit (2);}
     
    result = fread (buffer, 1, fSize, fp);
   
    if (result != fSize)
      {fputs ("Reading error",stderr); exit (3);}
     
    XorEncrypt(buffer, &key);
   
    fwrite (buffer, 1, fSize, fp);
   
    fclose(fp);
    free(buffer);
  // getch();
    return 0;
}

int XorEncrypt (char *string, char *key)
{
    int i, j, mod;
   
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6
   
    for (i = 0; i < (StringLen / KeyLen); i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] ^= key[j];
        }
    }
   
    mod = StringLen % KeyLen;
   
    if (!mod)
    {
        for (i = 0; i < mod; i++)
        {
            string[-mod + i] ^= key[i];
        }
    }
   
    return 0;
}

---

string[-mod + i] = string[-mod + i] ^ key[i];

The above highlighted items can evaluate to a negative number which is probably trashing your key variable making your encryption questionable at best.

I thought a negative number would cause to select a number from right to left, like:

char string[] = "abcdef";

then string[-1] would be f

But I just tested it and it seems I was wrong... I probably took that assumption from another language like PHP or something =S

But I beleive that this should fix it:

Code:

---

int XorEncrypt (char *string, char *key)
{
    int i, j, mod;
   
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6
   
    for (i = 0; i < (StringLen / KeyLen); i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] ^= key[j];
        }
    }
   
    mod = StringLen &#37; KeyLen;
   
    if (mod != 0)
    {
        for (i = 0; i < mod; i++)
        {
            string[StringLen - mod + i] ^= key[i];
        }
    }
   
    return 0;
}

---

Code:

---

>    XorEncrypt (&string, &key);

---

Try:

Code:

---

    XorEncrypt (string, key);

---

I did, but couldn't notice any difference.

Quote:

---

Originally Posted by lala123

I did, but couldn't notice any difference.

---

There will be no functional difference in the last version.

And by the way, negative offsets in arrays means[1] "the element before element zero", which of course is invalid for almost all circumstances you can think of. It is sometimes used for memory allocation:

Code:

---

struct allocInfo
{
    size_t size;
    struct allocInfo *next;
};

void free(void *p)
{
  struct allocInfo *pai;
 
  // find the block just before the memory given by the calling code.
  pai = &((struct allocInfo *)p)[-1];
  ....
}

---

[1] Well, technically, I think the C language defines this as "undefined behaviour", meaning anything can happen - mushrooms popping out of the keyboard, computer catches fire, program crashes, or whatever else you can imagine, but for most compilers I've used, it works the way it's described above, and it CAN be used sometimes, as long as the compiler is known to support this trick.

--
Mats

Just a point to bring up --- you have your "XorEncrypt" returning an int. My question is why? What do you do with the returned value --- nothing. So why not make it's return type "void". Not an error, but why make it return a value never used again?

Quote:

---

Originally Posted by matsp

[1] Well, technically, I think the C language defines this as "undefined behaviour", meaning anything can happen - mushrooms popping out of the keyboard, computer catches fire, program crashes, or whatever else you can imagine, but for most compilers I've used, it works the way it's described above, and it CAN be used sometimes, as long as the compiler is known to support this trick.

---

Well, since a[b] is defined as *(a+b), then a[x] is valid for any x so long as (a+x) is a valid pointer value. So this is valid:

Code:

---

char string[6] = "Hello";
char *endstring = string + 5;
char lastchar = endstring[-1];

---

Because endstring == string + 5, endstring[-1] <=> *(endstring - 1) <=> *(string + 5 - 1) <=> *(string + 4) which is valid.

Hmm. I must be confusing negative offsets with some other stuff that is UB then...

--
Mats

Quote:

---

Originally Posted by matsp

Hmm. I must be confusing negative offsets with some other stuff that is UB then...

--
Mats

---

Technically, you may not even possess, let alone dereference, a pointer to unallocated memory (whether it is automatic, global, static, or dynamic memory). The exception is that you can hold a pointer which points exactly one past the end of an allocated block.

But array accesses devolve to pointer dereferences. If the equivalent pointer dereference would be valid, then the array access is valid too.

Quote:

---

Originally Posted by brewbuck

Technically, you may not even possess, let alone dereference, a pointer to unallocated memory (whether it is automatic, global, static, or dynamic memory). The exception is that you can hold a pointer which points exactly one past the end of an allocated block.

But array accesses devolve to pointer dereferences. If the equivalent pointer dereference would be valid, then the array access is valid too.

---

Oh, sure, accessing memory you don't "own" is definitely UB - but there are certainly cases where one would be able to have a pointer INTO something, and use that pointer to figure out another pointer that is BEFORE that - which is what I've been using a negative offset to do.

--
Mats

Quote:

---

Originally Posted by matsp

Oh, sure, accessing memory you don't "own" is definitely UB - but there are certainly cases where one would be able to have a pointer INTO something, and use that pointer to figure out another pointer that is BEFORE that - which is what I've been using a negative offset to do.

---

Here's a long thread talking about the fact that merely assigning a pointer to point to something you don't own (other than one-past-the-end) is also UB, although most platforms let you get away with it.

http://groups.google.com/group/comp....18f6cccd56427d

Edit: Assigning NULL is also okay (as long as it's not dereferenced, of course).

So.... Does anyone know why my code ain't working? The executable runs fine but the file remains unchanged.

Quote:

---

Originally Posted by lala123

So.... Does anyone know why my code ain't working? The executable runs fine but the file remains unchanged.

---

Quote:

---

When the "r+", "w+", or "a+" access type is specified, both reading and writing are allowed (the file is said to be open for "update"). However, when you switch between reading and writing, there must be an intervening fflush, fsetpos, fseek, or rewind operation. The current position can be specified for the fsetpos or fseek operation, if desired.

---

So check the return values of th efunction called

vart

Amazing! It worked! Thank you =)

Here's the code in case someone wants it:

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    FILE *fp;
    long fSize;
    size_t result;
    char key[] = "123", *buffer;

    fp = fopen ("xor.txt", "rb+");
   
    if (fp == NULL)
      {fputs("File error",stderr); exit(1);}
     
    fseek (fp, 0, SEEK_END);
    fSize = ftell (fp);
    rewind (fp);
   
    buffer = malloc (sizeof(char)*fSize);
   
    if (buffer == NULL)
      {fputs ("Memory error",stderr); exit (2);}
     
    result = fread (buffer, 1, fSize, fp);
   
    if (result != fSize)
      {fputs ("Reading error",stderr); exit (3);}
     
    XorEncrypt(buffer, key);
   
    rewind (fp);
    fwrite (buffer, 1, fSize, fp);
   
    fclose(fp);
    free(buffer);
    getch();
    return 0;
}

int XorEncrypt (char *string, char *key)
{
    int i, j, mod;
   
    int StringLen = strlen(string); // 20
    int KeyLen = strlen(key); // 6

    for (i = 0; i < (StringLen / KeyLen); i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] ^= key[j];
        }
    }
   
    mod = StringLen &#37; KeyLen;
   
    if (mod != 0)
    {
        for (i = 0; i < mod; i++)
        {
            string[StringLen - mod + i] ^= key[i];
        }
    }
   
    return 0;
}

---

Well actually not really.....

When I use small strings in the file it works finely, but with larger texts and files...

Example: (using key "test43")

"This is a test!!!" -> " ZET@VRU" -> "This is a test!!!"

But when I placed the code (the same I just posted) and then passed the output I got:

Code:

---

#includ SHGGZ\
yoPZP]QZ
My>>~ ^\]] ESPXEUATOSE/8Zy>HyoST2,?1Hy>TES[]E']I^~~TE NV+SQ@
        O99TESTW[SQJ/8SIEW@V^RV^~~99TESTRCTXS[CS\K] LGVISVFQ_GZO99TEST99TEST]UTMIE=!x]hyTTESTOU2VFA]^SLZ MB]NyoSTTESy>TESGVS\RCXECX`1 8+q}0LHy>TESgZ SIU  ZO99TESTFVZO99TEST99TESTVFTX\E[]I
\W[Z^R`]>~EST>~ESTZE[AU
T        T+&8xyoSTTESRC
 T9 FJT
[AVI  PVZOVT
]^y>TESTyoST 
XGTXSFV
S\VFEISgZ _TRC]^~~TE~~TE 
XGTDNTR`]99TESTTAGE[VfV
S
FXQALHTQKS\O~~TEST>~ESTk6WA
\VF
]>~EST>~ESTAP\]>~ESTU Q\RVISE6QT]>~EST>~ESTU        QZO99TESTRA [AU
]>~ESTTOhyTT AAECO99        hyy>ZS,[A1MC E[\REY@AXP
TXZy>HyoSTT]T_TY\^~~TE~~TE@'
ZT8 T        
Q]\]]LHTTWCy>TESZGT.
xVENTGG        XZO[EEy>>~ESTUS\]IECOZTYS\gGxVE\TV
)TX_>~ESTHyoSTTESTR\E[TUHT^HE8MHT^_L~~TESThyTTESTTES@A/]?
8Q]TNSi*XSQJ/.O99TESTTEy>TES        99TEST99TESTY\ENTgGxVEVTV
)>~EST>~ESTZE[[WTDNTyoSThyTTEST

TZTXSDEOTY\^S]hyTTESThyTTESTTESTGGo` SSY^
S_Z)E-IX(iyoSTTESTNyoST        hyTThyTT AAECO99

---

=S There must be something wrong with the algo right?

Code:

---

#include
test43test43

---

What value do you get when you exclusive-or a letter with itself?
What do you think strlen() is going to do when it gets to that value?

Quote:

---

Originally Posted by Salem

Code:

---

#include
test43test43

---

What value do you get when you exclusive-or a letter with itself?
What do you think strlen() is going to do when it gets to that value?

---

If lala123 had been paying attention, he/she would have seen that I already pointed this out :rolleyes:

Oh, thanks for that. The code is working now.

Code:

---

int XorEncrypt (char *string, char *key, long sLen)
{
    int i, j, mod;
   
    int KeyLen = strlen(key); // 6

    for (i = 0; i < (sLen / KeyLen); i++)
    {
        for (j = 0; j < KeyLen; j++)
        {
            string[i*KeyLen + j] ^= key[j];
        }
    }
   
    mod = sLen &#37; KeyLen;
   
    if (mod != 0)
    {
        for (i = 0; i < mod; i++)
        {
            string[sLen - mod + i] ^= key[i];
        }
    }
   
    return 0;
}

---

Oh and BTW Im a man...

Quote:

---

Originally Posted by lala123

Oh and BTW Im a man...

---

Not like it matters, I just don't want to mistakenly refer to a woman as "he" or a man as "she" so I just use both :)

Ok :)