# Thread: Anyone see any vulnerabilities with this algorithm?

1. Hrmm...well, i'll try my best to explain how logarithms work. They are like the inverses of exponents. Let's say you have 2^x=8. To find x, you would do log base 2 of 8 = x. (I can't express it in decent mathematical form here really). For all purposes though, since most times when you use log, it's assumed that the base is 10, you can use the change base formula, which states that:

log base 2 of 8 = log base 10 of 8 / log base 10 of 2

I don't have a proof handy for this, and even if I did, it'd be ugly in text. You don't have to express base of 10 however in most cases, so, saying log 8 / log 2 is sufficient.

Note: This is a terrible overview of logarithms, it's just what came to my mind and what i remember about them. Go to wolfram's to get a better idea of it. http://mathworld.wolfram.com/Logarithm.html

Oh yeah, after looking there myself, i found there's a notation for base 2 defined as lg. Hrmm..interesting.

2. FlamingRain - After re-reading your explanation, I see exactly what you are planning on doing. And it should work. I'm supprised I didn't catch on to that earlier. I pushed that part of it into later on in the process (since it acturally happens during writing) and then forgot what was really going on to simplify it like you did.

Heck, with a bit more thinking you might be able to knock off a few of the numbers to try between 0 - 256. Because some keys *should* not be *likely* with how this program calculates them with that random * key + 3 stuff.

Anyways, I just want to see this happens now. I'm pretty sure you've cracked it already

3. *dances* I love this kind of stuff. I've got a bunch of boring classes today, excellent time to refine my cracking technique and write some software.

Perhaps I should post one of my crypto algorithms sometime and let people take a stab at it

I guess I had posted an older version of the .h file. Here's a new one.

Code:
```#include &lt;fstream.h&gt;

void encrypt(char *filein, char *fileout, long key, long key2); //encryption routine
void decrypt(char *filein, char *fileout, long key, long key2); //decryption routine
char ch;

void encrypt(char *filein, char *fileout, long key, long key2)
{
ifstream in(filein, ios::binary);
ofstream out(fileout, ios::trunc | ios::binary);

srand(key);
key = rand() % key2 + 3;
srand(key2);
key2 = rand();

while(!in.eof())
{
in.get(ch);
ch += key;
ch += key2 % key;
out.put(ch);
}

in.close();
out.close();
exit(0);
}

void decrypt(char *filein, char *fileout, long key, long key2)
{
ifstream in(filein, ios::binary);
ofstream out(fileout, ios::trunc | ios::binary);

srand(key);
key = rand() % key2 + 3;
srand(key2);
key2 = rand();

while(!in.eof())
{
in.get(ch);
ch -= key2 % key;
ch -= key;
out.put(ch);
}
in.close();
out.close();
exit(0);
}```
This algorithm successfully encrypted, and decrypted a file called netscan.exe. That attachment here will contain the source. A CPP which is a UI, and an H, which is the algorithm above. Also is a compiled version, with Dev-C++. I'll have another post containing the netscan and it's encrypted version. I changed the extension of Archive.exe to a .ZIP so I could attach it here. Rename the file to Archive.exe, and extract everything.

5. Um...this code is significantly different from what you posted earlier. The multiplication has changed into modulus. And it no longer adds and subtracts even/odd parts of what it is encryption/decrypting.

Breaking this is simply a question of picking from among 256 different numbers to subtract (as FlamingRain pointed out earlier, except now there is no add step for even/odd). No matter what you do with your keyspace here, when it goes to encrypt, you get like 8-bits of security. Collisions galore! Given you can give this program 2^64 combinations for the input, that there are billions of trillions of password collisions! Extreamely bad. When you design and implement something in cryptography, collisions are your worst enemy because they reduce security.

If I was to give you a number that reflected the number of passwords you could choose compared to how well it was encrypted...Microsoft's calculator gives me 0.0000000000000000013877% (that's 17 zeroes!).

Definately needs work on implementation. Think of it like this: when other programs go to encrypt, usually different parts of the key (that is at least 4 characters long) work on every 1st, 2nd, 3rd, or 4th bit. That is basically 32bit encryption. They must work on more than one bit like this to improve security. Because in the end, all of the data is represented as a number between 0 and 255 in a series of eight 0's and 1's.

Also, please don't ask people to execute programs. You can usually include the program if you include source (so we have a choice, although we usually compile), but please just post a plain zip file. I've unarchived it from the EXE and posted a regular ZIP of its contents for those not wanting to take chances.

6. Hrmmm, well, with the code change, this makes for an interesting new problem. However, I would suggest that you look more carefully at your key generation methods. I looked at the rand function on my TI-BASIC (yeah, I know they have nothing to do with each other, it's just an example) and played with it and found out there are STRONG correlations in the data output by a seeded generator. I'm going to write the program in C and see what kind of correlations there are with your key generation method. ALSO, you seed the generator and then only generate a single number from it, which means that I can pick all values for your key and easily codebook the input and output keys. I don't know what range rand() generates numbers in, but, i'm assuming it's going to be a 32-bit integer. So, I'll get to work on finding the outward keys in relation to the inward keys and see how it looks. What's cool about doing this is that you can see key distributions on a scatter plot. If all the points are fairly evenly spread and in mostly organic patterns, you've got a good generator. However, if there are large holes or tightly concentrated areas, the key generator needs work.

I'm gonna get to work on my crypto basics tutorial set soon I guess. They'll cover:

Substitution methods and strengths:
-Mono Alphabetic
-Poly Alphabetic
-Homophonic

Fractionation:
-Basics
-Fractionation considerations

Transposition:
-Columnar and variations of it (unkeyed, keyed, patterened)
-Grid

Other funky constructs:
-Latin squares

Computer crypto basics and crypto math:
-Basic bitwise logic
-S-boxes
-Shift registers
-Basic block-cipher concepts
--Block cipher modes:
---ECB
---CBC
---CFB
---OFB
---others...
-Asymmetric crypto

-Analyzing keyspaces and key distributions
-Determining the "randomness" of a random number generator
-Constructing good key generators

Basic cryptanalysis:
-Patterns
-Statistical attacks
-Applying what you know
-Normal attacks

Actually, for educational purposes, I've got my latin squre cryptosystem up on my site. It's basically composed of a latin square system, a key generator, and a fractionator/mapper. It can be found on the coding section of my site: http://cypherpunk.8bit.co.uk/coding.html

I'm not trying to plug my site here :/ I'm really just not fond of pasting a ~1k line euphoria program in the thread.

7. It appears that your cipher is a fairly trivial variation of a caesar cipher. The key may be 64bits, but I suspect only 8 bits are actually relevant (as others have suggested).

Therefore there are only 256 distinct keys. With any reasonable guess as to what the original data contained, the key could be brute forced almost instantly.

Additionally, even not knowing the algorithm, frequency analysis of the encrypted file could yield a working mapping to obtain the original file if some of its contents were known approximately.

So as far as strength goes, I'd say your main weaknesses are:

- Considering the file 1 byte at a time with no persistent data byte-to-byte is probably a bad thing
- Throwing away most of the key is a bad idea. Each possible key should produce a different encrypted data, or there is no point.
- The distribution of bytes, pairs of bytes, words etc, in the output should be apparently random regardless of the input data, to make frequency analysis more difficult. Most block ciphers work on a block that is at least 64bits, not 1 byte.

Please ensure that all code you post has been compiled, tested, and verified. Ideally post a test program which demonstrates its effectiveness, at the very least:

- Several different sets of data should be encrypted and decrypted with the same key (several different ones) and then compared with the original
- Some data should be encrypted and decrypted with different keys to ensure that they are different.
- Try flipping just one bit in the key, the data should still be different.

Slarty

8. Wow. See, I'm a complete newbie to cryptography, and I don't really understand how you're calculating the bits of security, as mine is said to be 8-bit. This is my first attempt. I apologize for not reviewing the code before first posting it. I assumed I had copied the newer version to my back-up. If I could get a little more background on how there are only 256 keys, and how that's considered 8-bit security, it'd be much appreciated. Thanks alot for your feedback, though, it shows I have much to learn.

9. At least you're taking this as an opportunity to learn. Which is better than say, trying to come up with a latest and greatest patch to it and asking us to test it again.

The way we came up with 256 different keys, is pretty long winded if you want to really understand how we get it. But I'll do my best to explain because it is an excellent opportunity to get a good understanding of this stuff.

Basically, when you are reading from and writing to your file, the program gets data in 8-bit chunks. An 8-bit chunk of data makes up a byte, which can store any value from 0 to 255, or 256 distinct values. At the lowest level, your program works with these individual bytes of data from the file. It reads a single byte, performs your encryption algorithm on it, and then saves the new byte into a newly encrypted file. It repeats this until the end of the file.

Each and every single byte has the exact same operation performed on it, so they change by the same amount. IE, both the first byte, and the last byte, and every byte inbetween, could have the number 20 added to it. Provided no buffer overflows occur, IE the code would make too-large numbers like 266 become 10 to fit correctly in its byte, all of the data would remain intact. But no matter what you add to the byte you read, it will always have to be changed to fit between 0 and 255. This is one issue -- you could add some number like 314159 to every byte you read from the plain-text, but the cipher-text would always have to be between 0 and 255. So in the end it would be one of 256 values, and each byte would be moved the same amount.

So no matter how big a password you give to your program, it always works on things one byte at a time. When you have more passwords possible that differing (encrypted) output is possible, you get things called collisions. This is where more than one password can create the exact same output text. This is bad, because it means I don't acturally have to find the exact same password you used, but I can infact find one that collides with it, which can double or better my chances of decrypting the file, even if I don't ever find your paticular password. When collisions happen left-and-right, I might decide to look at the lowest level of the algorithm and find out why, and then work out a way to simply calculate only the collisions so I can cover more password-conbinations at a time than normally possible (because multiple passwords have the same output/results).

We figured out that your program has only 256 possible outputs for any one file, with the other passwords simply colliding everywhere. So the best way to crack a file, based on how your program works, is to try adding every number from 1 to 255 and seeing what looks like it would be the original output. We only calculate and try the collisions, since there are 256 of them that represent all of the passwords, instead of trying each of the trillions of password combinations of which most of them produce the same results anyways. It saves a lot of time that way.

Probably the next obvious question is how would 16-bit encryption work. Basically, it works on two bytes at a time. If used perfectly, we'd have to try guessing 2^16 times before getting the correct output (two bytes change, which is 16 sets of binary digits). As more commonly (mis)used, we could probably guess about 512 times (instead of 65538 times) to decrypt/crack the file. If someone writes programs like this thinking it is uncrackable, and keeps scaling it to the 1024-byte mark...ouch. Because it is possible to have something fundamentally flawed, yet be used at proportions big enough to be a PITA to work with, and sell it as some propitary encryption technique, when it is really Snake Oil.

I suggest you play with the XOR operation to get something that works well, and is used in the ultimate one-time pads. Basically, start by writing a program that takes some password input (in character format). Then, it reads a byte from the input file. It will XOR the first byte of the file with the first byte of the password, and save it in the encrypted file. Next, it will XOR the second byte of the file with the second byte of the password. It will continue this until it gets to the end of the password, and then start the password from the beginning again. IE, the 9th byte of the file might be XOR'ed with the first byte of the password.

XOR is fun because when you go to decrypt, if you give it the password and encrypted data, you get the decrypted file. Also, if you give it the encrypted data and the decrypted data, you get the password.

Anyways, in Plain C, XOR is "^" IIRC. So just write a new program and try it out. Should be a lot of fun. And keep asking questions if you need help with something, this paticular sub-forum doesn't see as much action as it should...

10. Yea, I had messed with XOR not too long ago, but couldn't get the *de*cryption part to work...so it was a failed attempt. How would you measure the encryption on XOR, because it does do one 8-bits at a time, but they are encrypted differently each time...
This thread has definitely become quite informative. Thanks alot Tim_Axe and FlaimingRain for your help.

A_T

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•