could you crack this please

[ark_templar]

I made a program in C which encrypted a text message
the output is in the attached file could you please crack it.

also im putting my prog below so if you could play devils advocate with it
(and sorry but posting ruined my indentation)

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

#define BUFF_SIZE 512

int encrypt(void);
int decrypt(void);

int main()
{
int choice,was_error=0,for_pause;
printf("encryption program menu\n");
printf("1. encryption\n");
printf("2. decryption\n");
printf("enter yor choice:- ");
scanf("%d",&choice);
printf("\n");
switch(choice)
{
case 1:
fflush(stdin);
was_error=encrypt();
break;

case 2:
fflush(stdin);
was_error=decrypt();
break;

default:
printf("you entered an invalid choice\n");
break;
}
if (was_error==-1)
printf("\nan error occured task unsucessfull\n");
else
printf("\ntask completed sucessfully\n");
scanf("%d",&for_pause);
return(0);
}

int encrypt(void)
{
int i;
FILE *fencrypt;
char string[BUFF_SIZE],first_half,second_half,second_encrypt;
char first_encrypt,first_bluff;
fencrypt =fopen("encrypt.txt","wa");
if(fencrypt!=NULL)
{
printf("enter the text\n");
i=0;
gets(string);
while((string[i]!=NULL)||(string[i]!='\0'))
{
first_half=(string[i]&240);
second_half=(string[i]&15);
first_encrypt=(first_half^i);
second_encrypt=(second_half^(BUFF_SIZE-i));
if(rand()%2==0)
first_bluff=65+(rand()%65);
else
first_bluff= 97+(rand()%97);
fprintf(fencrypt,"%c%c%c",first_encrypt,first_bluff,second_encrypt);
printf("%c%c%c",first_encrypt,first_bluff,second_encrypt);
i++;
}
fprintf(fencrypt,"\n");
fclose(fencrypt);
return(0);
}
else
return(-1);
}

int decrypt(void)
{
char fname[32],first_half,trash,first_encrypt,second_encrypt;
char second_half,letter;
FILE *fencrypted,*fdone;
int i=0,words_scanned=0;
printf("enter the file name of the file to be decrypted: ");
scanf("%s",&fname);
fencrypted = fopen(fname,"r");
if(fencrypted!=NULL)
{
fdone=fopen("decrypted.txt","w");
if(fdone!=NULL)
{
while(!feof(fencrypted))
{
switch(i)
{
case 0:
first_encrypt=fgetc(fencrypted);
first_half=(first_encrypt^words_scanned);
i=1;
break;
case 1:
trash=fgetc(fencrypted);
i=2;
break;
case 2:
second_encrypt=fgetc(fencrypted);
i=0;
second_half=(second_encrypt^(BUFF_SIZE-words_scanned));
letter=(first_half|second_half);
fputc(letter,fdone);
printf("%c",letter);
words_scanned++;
break;
}
}
fclose(fdone);
fclose(fencrypted);
return(0);
}
else
return(-1);
}
else
return(-1);
}

[ark_templar]

oh yea BTW thanx in advance

[AxessTerminated]

I can take a look at it, see what happens, I'm short on time. But when you post code, use the CODE tag. you enclose the word 'code' inside []. then after the code is done, you enclose "/code" in [].

#include <iostream.h>

main()
{
cout << "Hello World!";
system("pause");
exit(0);
}


A_T

[S3cur|ty4ng31]

this is a test to see if you can crack the text im sending you so you had better not guess^

[FlamingRain]

There's no key input? Why try to crack it when it is sufficient to just run the decrypt function on it? I haven't taken a hard look at it to try to reduce it, but, without a key, i'll simply end up with a shorter algo to decrypt if there is one.

[poohsuntzu]

Careful!

system("pause");

That is a windows only usage of C!!!! Meaning that pause is only going to register on windows machines. Shame shame shame!

[Tim_axe]

My post may be considered a bit harsh, but it is a criticism of your posted code after I had taken some time to review it.



Why do you even write first_bluff when your decryption routine doesn't make productive use of it? It just serves to increase the filesize 150% (encrypted file could be 33% smaller than it currently is). It is also a calculation that slows down the process of encryption. Extraneous data and slower calculation rates are not really goals to meet.

What you appear to have here is some intricate stitching of XOR with a very predictable linear function (position in file), while using the modulus of the input to break the data to encrypt into two parts (first_half, second_half) to be combined later after XORing it with the original function and dumping a garbage piece (first_bluff).

If you replace the linear function (position in file) with a choice of the user to provide a key, it *might* be more "protective". As it is right now, it is just a mess of code that basically XOR's a byte in the file with it's position in the file, and produces a file 3x the size.

I recommend that you study classical cryptography, and maybe pickup a book or two that should be mentioned somewhere in a post in this sub-forum. Unless you are into some really high level math courses (maybe College-level Calculus would suffice if you really understand it), you'd be much better off analyzing current algorithms instead of trying to build your own. I've tried building my own, but failed miserably, so I instead spend some of my time disecting what others have done in my free time.

[ark_templar]

umm
i actually meant for you guys to try and crack it without the decryption algo
but thanx any way and could you explain the concept of an encryption key
whats its aim if the algo of encryption is unknown then I think (thats what I wanted to test)
that the thing is pretty much unbreakable

well any further input would be appreciated and i do have calculus and leniar algebra under my belt so hope to come up with a good one this is just my 40th program in C so
I didnt expect miracals (hope the spellin is right but the spell cjheck hangs my comp)
any way thanx all

[Tim_axe]

whats its aim if the algo of encryption is unknown then I think (thats what I wanted to test)
that the thing is pretty much unbreakable

Well, your conclusion isn't completely true. In the various world wars, encryption technology was attacked heavily since the opponents relied on encryption to keep their operations secret and effective. With the help of various mistakes (not changing keys, predictable messages, and also "losing" encrypting machines, etc) the different codes were cracked. The only exception I think was the Navajo Wind-Talkers. But basically, if you have enough data, you can usually find patterns (linguistical patterns, etc.) to attack, and eventually break algorithms. But, one important thing to note is that the industry pretty much only considers publicly published and scrutinized algorithms (RSA, etc) as secure. If nobody can analyze it, nobody could find weaknesses that could be hiding, intended or not.


I'd do a bad job at trying to explain what an encryption key is, so you might want to read about it somewhere else, but basically it is a variable that the algorithm depends on to properly encrypt and decrypt a message. If you use the wrong key for an encrypted message, you would get gibberish as output; only the correct key for an encrypted message would give you the original message...


Cheers.


BTW, I don't consider straight XOR secure unless it is used in a One-Time-Pad. It offers 2^x combinations (x in bits), but the worst case is closer to x*32 combinations (x in bits) when x is larger than 8 or so. Basically, any x-bit long key (x > 8 bits) is actually many times weaker (x*32) than it appears (2^x). But this doesn't apply in a One-Time-Pad situation (key never repeats and is completely random), but rather with x-bit long keys (where the key must repeat several times throughout the message).

Keep at it though, and hopefully you'll come up with something interesting. Math is fun :)

[unhappy]

why do i get an error "NULL used in arithmetic" when he's comapring it to string

[unhappy]

he's comparing a character from string[n]

[Relyt]

ark_templar

Tim_axe made some very important points and if I may add to them a bit...

Encryption can be deciphered given enough time. The secret to keeping your secrets secret longer, lies within two processes. First you must have a very strong tested and tried algorithm. However don't be fooled into believing that the algorithm is the most important part because that is simply not true. And the second part, the most important, is keeping the "Key" secret and changing it frequently.

Does this mean it can't be cracked? No. However make the guy pull his hair out trying and by the time he may have figure part of it out, you've changed the key on him or the secret no longer requires safeguarding.

Here's a tutorial with more info:

http://www.antionline.com/tutorials/jump.php?493

Additionally here's a link the encryption tutorials:

http://www.antionline.com/tutorials/?c=89

cheers

[;TT]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=264673#post811796) by poohsuntzu
Careful!



That is a windows only usage of C!!!! Meaning that pause is only going to register on windows machines. Shame shame shame!

Ok, I don't ****ing get this? What does this have to do with ANYTHING?! He posted an example of how ot use the VB tags ["code"] and then your comment for some reason is flaming green for an inane comment that has 0 to do with the discussion at hand... wtf is going on?

[Donkey Punch]

Ok, I don't ****ing get this? What does this have to do with ANYTHING?! He posted an example of how ot use the VB tags ["code"] and then your comment for some reason is flaming green for an inane comment that has 0 to do with the discussion at hand... wtf is going on?

Perhaps he was pointing to portability, but that was not the point in the orginal post. It makes no difference. The legacy of AntiOnline continues and will not change. Get over it.

[skiddieleet]

:hearts:

[poohsuntzu]

I'm sorry, did the cranky-old-men have a problem with me mentioning portability problems I found in code he asked us to review and posted? And yes he did ask us to take a look at it.

also im putting my prog below so if you could play devils advocate with it
(and sorry but posting ruined my indentation)

Come on, I dare you to tell me I'm off topic when you won't even read the parent post.

[unhappy]

if you want your code to be portable you can use "getchar()" fuction to pause the execution untill the user presses a key

just my 2 cents

[ark_templar]

people thankyou for responding the responses have been helpfull esp. Reylt and tim_axe
thankyou for the links as well
hope you guys dont mind if i create a new post soon with a new (and hopefully improved) algorithm (I'll be bak ).
well thanx all and i'm sorry that you guys started flaming eachother on my page but end it now once again
hastalavista but I'll be bak ;-)

[Linen0ise]

Buffer Overflow:

printf("\ntask completed sucessfully\n");
--->scanf("%d",&for_pause);
....
}


It will keep looping until a number is entered. Imagine alot of characters or "hex" numbers were entered

[0x7e]

i hope you all will forgive the slightly pedantic interjection of an outsider, but ark_templar brings up an interesting point about arbitrary transformations when he asks, "could you explain the concept of an encryption key whats its aim if the algo of encryption is unknown then I think (thats what I wanted to test) that the thing is pretty much unbreakable." this is a topic in "nonlinear algebra" which interests me.

in a sense, encryption is just an arbitrary mapping from a string of data (a vector) to another string of data. decryption is accomplished by guessing an inverse mapping which maps the encrypted data back to the original data. it does not require one to know exactly what algorithm was used to encrypt the data in the first place. in fact most reasonably simple keyless algorithms have the same inverse mapping, up to a variation in a couple of parameters. a good encryption algorithm has very few inverse algorithms regardless of the simplicity of the encryption itself. this is the purpose of the key. the key is an arbitrary set of steps in your encryption whose sole purpose is to reduce the number of inverses to your encryption. modifying a keyless encryption algorithm is, at best, equivalent to changing a couple of bits of the key of a keyed algorithm, and thus we can much more efficiently increase the difficulty of cracking our encrypted message by incorporating arbitrary, randomly generated keys into our algorithm than by trying to write more or different steps into it.

and tim axe, i may be mistaken, but i think that while the allies cracked the nazis' encryption due partly to stealing the machines off of sinking submarines, the allies codes remained intact through the end of the war. the fact that the wind-talkers code remained tight through the war is more a testament to human bigotry than mathematical brilliance, methinks. the polish resistance under nazi occupations used, as radio call signs, surnames such as brzeszczesciekiewiec (sp?) to assure themselves that they could not be infiltrated by nazi trojans, and to great avail. never underestimate a brilliant mind's unwillingness to extend his intellectual powers outside his own cultural bounds. to that end, a great read for ark_templar would be stephenson's cryptonomicon, which covers in great detail the world war two history of cryptography and its mathematics, be it only a novel.

and on a more extraneous note, does anybody know how to set up encrypted swap partitions on a linux box? i figure it's kind of silly to encrypt a filesystem if the key is going to sit in memory and then perhaps be written to the swap partition, whose persistence is god knows how long.

forgive the length of my wind.

[|3lack|ce]

0x7e - Look at the post above yours. See the flashing date? This thread is well over a month old now. It's a common mistake here to newbies - and the response is always the same:

Check the date before you post!

Have fun.