Encryption

[hazmaz]

I've been trying to write a basic encryption algorithm, not really
intended for use as a secure means of protecting data, but to help me
learn things like bitwise operations.

Just wondering, how easy would it be to crack what I've come up with:

FILE * inFile;
FILE * outFile;
this->inputfile = infn;
int k = 0;
char pc = 211;
char ppc = 47;
int count = 17;
int klen = this->key.length() ;
string key = this->key;
char nc;
char encChar;
int counter = 347;
int offset;
string out;
inFile= fopen(infn.c_st r(),"rb");
outFile= fopen(outfn.c_s tr(),"wb");
char khash1 = key[0];
char khash2 = key[0];
char khash3 = key[0];
for(int kle=0;kle<key.l ength();kle++){
khash1 &= key[kle];
khash2 |= key[kle];
khash3 ^= key[kle];
}
nc = fgetc(inFile);
int forloops;
GetFileSize(&fo rloops);
int fl = 0;
for (fl;fl<forloops ;fl++){
counter++;
encChar = (key[k]^nc);
encChar = encChar^(pc^ppc );
ppc = (pc+((key.lengt h()*(key[k]+4))*(count++/23)));
pc = encChar;
offset = ((counter++)%(k ey[k]));
encChar += offset;
encChar ^= khash3;
encChar ^= khash2;
encChar ^= khash1;
fputc ( encChar, outFile );
k=(++k<klen?k:0 );
nc = fgetc(inFile);
}
fclose (inFile);
fclose (outFile);

Thanks,

Harry

[mlimber]

[e-mail] m wrote:

I've been trying to write a basic encryption algorithm, not really
intended for use as a secure means of protecting data, but to help me
learn things like bitwise operations.

Just wondering, how easy would it be to crack what I've come up with:

[snip]

You're in the wrong newsgroup. Here, we discuss the C++ *language*, not
arbitrary algorithms and applications. See this FAQ for what is
on-topic here:

http://www.parashift.com/c++-faq-lit...t.html#faq-5.9

Cheers! --M

[Jerry Coffin]

In article <11************ **********@75g2 000cwc.googlegr oups.com>,
ha****@gmail.co m says...

[ Warning: this post is long and only marginally topical at best... ]

Just wondering, how easy would it be to crack what I've come up with:

[ ... ]

counter++;
encChar = (key[k]^nc);
encChar = encChar^(pc^ppc );
ppc = (pc+((key.lengt h()*(key[k]+4))*(count++/23)));
pc = encChar;
offset = ((counter++)%(k ey[k]));
encChar += offset;
encChar ^= khash3;
encChar ^= khash2;
encChar ^= khash1;

The first thing you should realize is that exclusive-or is
commutative, so ((a xor b) xor c) is equivalent to (a xor (b xor c))
(and likewise if you add a 'd'). So, your first step in figuring out
what this really does is to take that into account. For example, the
last three lines in the loop are equivalent to:

// this outside the loop:
khash = khash1 ^ khash2 ^ khash3;

// and then this in the loop:
encChar ^= khash;

Ultimately, what you have seems to reduce to:

ch ^= X;
ch += Y;
ch ^= Z;

For appropriate definitions of X, Y and Z.

Since Z remains constant throughout, it has no real effect on the
relative frequencies of characters, so for most practical purposes
it's a NOP. The way you've defined Y is almost more troublesome -- I
suspect in effect, it ends up giving the attacker more information
than he'd have without it. Consider what happens if you encrypt a
message that starts out as all zeros. For each character, Y starts at
0, increases to key[n], and the cycles back to 0 again. As such, here
you almost have things working in reverse: the main thing that's
keeping your key secret is the fact that it's being "encrypted" using
the original text as the encryption key. If that wasn't happening,
you'd be sending the key, ready for the attacker to use it.

In particular, if I take two messages that were encrypted with the
same key, I can xor them together, and everywhere the letters in the
original messages were the same, what I have left is your 'counter++
% key[k]'. Given the redundancy of normal text, that's going to
happen quite a lot. It won't take a whole lot of analysis of the
result to find your entire key.

Your definition of X is almost certainly the most useful. In
particular, it's the only one that forms any chaining effect --
making the value of one output character depend not only on input[n]
and key[n], but also on input[n-1] and key[n-1]. Unfortunately, I'm a
bit uncertain about some of it -- in particular:

ppc = (pc+((key.lengt h()*(key[k]+4))*(count++/23)));

looks more or less like you picked it almost randomly -- it looks as
if 23 (for one example) was pretty much just an arbitrary number.
Ultimately, I'm not sure how much all this machination really
accomplishes (if anything at all).

While I haven't attempted a serious attack on this, my immediate
reaction isn't particularly positive. I'm fairly certain anybody who
bothers to work through this:

http://www.schneier.com/paper-self-study.html

(for only one obvious example) can break your cipher fairly easily.

--
Later,
Jerry.

The universe is a figment of its own imagination.