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