• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# encryption scheme

## Recommended Posts

KalvinB    102
Project page with source, exe, example and explaination I''ve come up with a way to a create a seemingly random and infinitly sized key to encrypt files. How easy would this be to crack without the key? Is it something worth using? Ben [The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
Beer Hunter    712
The key is not random and infinite if it''s generated mathematically.

Anyway, here''s some things to look at:

1) Some keys will be weaker than others.
2) Let A and B be files you want to encrypt, and C be the sequence generated by a key. If A and B are -both- encrypted with C, then after encryption, you have A^C and B^C. If someone intercepts these files, then they can easily find A^B, which can be recovered (by an expert).
3) If I start guessing parts of the original, unencrypted file, then I can just xor it with the encrypted file to find part of the generated sequence. Then I can use that, and the position in the file, to find a pretty good guess for the key.

4) The pow() can be replaced by one multiplication per iteration.
5) Four lines:

if (ch==''+'')
else

One line:

Problems 2, 3, 4 and 5 should be easy to solve, but number 1... I don''t know.

##### Share on other sites
KalvinB    102
To test the "randomness" of the key it would be possible to output the results of the equation to a raw file and see what the image looks like.

1) running your key through a bitmap works best for testing. For instance, if you set your key file to

12
d

Then just use a paint program to load the raw data. The picture will be messed up a bit but still recognizable. That''s where with the sample pic at the site you can see just how "random" it comes out. Applying that key to any file will distort it just as much.

Also compare compressing the original file to compressing the encrypted file. The closer the two are in size, the worse your key is.

2) Never use the same key twice. Adding in an extra power to the equation for each file or changing a number is easy.

3) If I just gave you the encrypted file the odds of you guessing it was the unabomber would be pretty low. This basically comes down to making sure the key creates a file that has zero resemblence to the original.

implementation
4) Breaking that down would just add a second loop rather than using a predefined function that does the same thing.

5) I''ll change those.

Thanks for the feedback. This is pretty much a "because I can project" and also a good intro project to linked lists.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
Shannon Barber    1681
You can definetly see a pattern in the encrypted data. A really good encryption scheme will look like gussian-noise.

##### Share on other sites
KalvinB    102
That particular equation sucks much. I created one that had no discernable pattern in a 350x480 image. Very colorful.

You really just have to mess around and with key values for a bit. Dividing by prime numbers seems to work best.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
EvilCrap    134
like all things,
before you go about trying to figure out how to encrypt, you need to think about what encryption is, what it is used for, how it is used, and etc.

there are several steps to encrypting. first off, you need to do a sort of uml.
-what are the capabilities of my platform?
-how long does the encryption need to be secure?
if a specific algorithm only needs to perform for, say, a few seconds, then complexity may not be as much of an issue compared to an algorithm that needs to be secure for a decade.
-how does it need to be decrypted?
by computer, hand, mental-figuring; keys, equations, masks, etc
-how should it not be decrypted?
etc etc...

there are several steps to make an effective encryption:

-first, disassociate the infromation from its true nature - - hide it in a bitmap, for instance.
-2, alter the data frequencies - - if you are encoding a text file known by interceptors to be english, then you want to destroy the known frequencies of letters in english words...
-3, make a useful and practical encryption scheme, thats for u to research.

i dont think an expert (im not a cryptanalyst, fyi) would have a problem with ur method.

there are ways of encryption that are impossible to break.
one of the easiest ways is using much data to represent values, and also much useless data.

for instance, create a bitmap in word, draw a bunch of text of varing colors and crap on it, and then type some relevant text somewhere ... the *file* will have so much info in it, its impossible to crack for several reasons. 1) each element of data is composed of many bytes, the letter ''T'' being x pixels of y depth. 2) there are slews of random, unrelated data among relevant data. 3) you can apply encryption to the actual text prior to insertion.

these ideas can be applied to software too, i have seen programs that reorganize stuff so it cannot be decompiled easy. with files, you simply need to disassociate the data from known interfaces, like word or paint.

##### Share on other sites
Beer Hunter    712
1) Yes, it''s pretty easy to check how strong the key is.
2) Other encryption algorithms don''t have that limitation.
3) Fine until you try to encrypt text (such as confidential documents).
4) You don''t need a second loop when you can re-use the first one. What you''re doing is (effectively) this:

for(int i = 0; i < 20; ++i) {
printf("%i ", (int)pow(2, i));
}

What I''m recommending is this:

int power_of_2 = 1;
for(int i = 0; i < 20; ++i) {
printf("%i ", power_of_2);
power_of_2 *= 2;
}

##### Share on other sites
KalvinB    102
I updated the source and exe which now produces the .enc.raw which is the full key image and .enc which is the encrypted file

There''s a new encrypted pic with a new key to demonstrate just how distorted it can get with a good key. Maybe there''s a pattern in there somewhere.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
HenryApe    120
Why not just use a published algorithm developed by real cryptographers?

##### Share on other sites
Guest Anonymous Poster
Writing a good PRNG (pseudo random number generator) is the key problem and one of the most difficult tasks in the field of cryptography. You won''t believe the methods good cryptanalysts have to break PRNGs. Yours is, sorry to say, a very weak one. The formula is mathematically not secure in itself. If you know (in the slightest detail) the cryptanalytic methods used by professionals (eg. if you are a professional yourself), then you can specifically design a formula, that is more resistent against those attacks. Those equations typically are full of mathematically non-reversable tricks, prime numbers, permutations, hashing tables. And even complex PRNGs are broken.

Looking at a noise image doesn''t say much of the real quality of a PRNG. You have to go a lot deeper, if you want to track it''s security: probabilities for certain bitpatterns to appear, repeating patterns, constant shifts, etc. Eg. you have to analyze, if bit 3 of each byte output has a probability to be more often a 1 (instead of a 0) each fifth byte, in that case, it is a weak point. Just a single example, in reality, it''s a lot more involved. It''s real hard mathematic work, and it can take years by professionals to give the label ''secure for use'' to a new PRNG.

Have a look at http://cnscenter.future.co.kr/crypto/algorithm/block.html#analysis, you might be shocked to see *what* kind of methods cryptanalysis uses. I''d say, stay with proven technology. That''s even more important in the field of cryptography.

- AH

##### Share on other sites
KalvinB    102
Why not just use a published algorithm developed by real cryptographers?

What fun is that? I've had this idea for quite awhile and I just decided to spend a few hours putting it together and see how well it would work in the real world.

AP:

I'll add in counter to see how often each bit shows up in that picture and post the results.

for the key:
1 40715 0 40702 //128
1 40938 0 40479 //64
1 40750 0 40667 //32
1 40895 0 40522 //16
1 40820 0 40597 //8
1 40508 0 40909 //4
1 40616 0 40801 //2
1 40705 0 40712 //1

for the image:
1 40650 0 40767
1 40818 0 40599
1 40571 0 40846
1 40361 0 41056
1 41194 0 40223
1 40785 0 40632
1 40656 0 40761
1 40477 0 40940

Ben

Edited by - KalvinB on January 31, 2002 2:43:51 PM

##### Share on other sites
EvilCrap    134
actually, i take back what i said earlier... for the most part, ur code is *not* impossible to break... however, in that particular application, of incoding an image, it is.
its not possible to decode fixed-data + random-data. fixed data is ur equation, and the random data is ur image. actually, this is complex topic because ur data isnt truly random, there are maximum and minimum values, and ur picture is a self defining pattern. but in general, ur picture of that criminal is secure.

BUT to talk about general encryption,

i am seriously sick of people using math to encrypt. math = logic = patterns. yes, math needs to be used with data, but it cannot be used with information. data != information.

dont use an equation to encrypt ur information. math == pattern == same information different pattern.

you need to destruct the information. take ur cat, chop it up, and have god glue it together so it acts and looks like a camel -that is destroying information.
because the entire point of encrypting revolves around information, this lession is extremely important.

take ur file, your image, and destroy the image, and then encode the data.

for a text file, destroy the language frequencies, and then encode the data.

etcetcetc.
next to last, disassociate the information.
lastly, hide the information so that it is not special or outstanding.

keywords that u can have enlightening fun learning and thinking about:

data
meaning
information
comprehension
interface, grammer, syntax

association
organization

Edited by - evilcrap on January 31, 2002 2:46:13 PM

##### Share on other sites
Guest Anonymous Poster
> take ur file, your image, and destroy the image, and then encode the data.
> for a text file, destroy the language frequencies, and then encode the data.

A good encryption system will make exactly that unnecessary. Your data will look and behave like noise. Chopping up the data doesn''t add anything to a good cipher, but has no negative effects either (any noise pattern combined with another *unrelated* noise pattern, can only be more random than before). This is exactly the purpose of a good cryptoalgorithm: to deviate the potential attack on patterns towards the key instead of the plaintext. It is made mathematically impossible to run pattern analysis on the encrypted data (even if you have a copy of the unencoded plaintext !), *without* running it on the key itself first. So it is not important, if your plaintext data has patterns, it may be text, graphics, or even a whole file filled with zeros. You''ll have to cryptanalyze the *key* first, and that''s where patterns are dangerous.

KalvinB: if you want to run some cryptanalysis on your algorithm, there are some standard tests to get a first impression of the algorithm''s security. If you like, I can try to find the URL somewhere on my HD.

- AH

##### Share on other sites
Guest Anonymous Poster
Your bit pattern distribution doesn''t look too bad. But the bitpattern distribution *per byte* looks also very 50/50% if you do a simple rand(). The key is to analyze, if certain bit combinations repeat after a certain sequence, or if they are in *any* way related to each other.

Examples:

* is it more probable, that a 1 bit will arise at that position, every 10th byte in a row ?

* Does bit 4 tend to be more often 0, when bit 6 is 1, and bit 7 is 1 too ?

* Does the bit sequence 1101 repeats itself in a non-random way ? Perhaps shifted by 2 bits everytime ?

* Does bit 1 tend to invert itself, if bit 7 does that too ?

Remember, the output of a ''perfect'' cipher is 100% *pure* noise. No correlation, not the slightest. Every correlation is a potential security breach.

- AH

##### Share on other sites
KalvinB    102
All the numbers in the below list should be zero. These are percentages for how far off from ideal each bit and byte number is off.

Each bit should appear 6.25 percent of the time and each byte should appear 0.39 percent of the time.

list of percentages off

In that respect there doesn''t appear to be much of a skew towards any bit or byte number. The amount off for any bit or byte is around 1/100th of a percent.

Whether or not there are bit patterns has yet to be proven. If you could post any links to existing programs that could do the work, that would be great. I''d like to see just how well this works. It looks like it''s got the basic requirements of even amounts of bits and bytes and no visual pattern.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
Guest Anonymous Poster
> Whether or not there are bit patterns has yet to be proven.

Hehe I think it has to be proven, that there are no bit patterns. Pro cryptanalysts work years on this phase, before a new algorithm is considered ''safe''...

> If you could post any links to existing programs that could do the work, that would be great.

OK, I''ll look into that.

> I''d like to see just how well this works. It looks like it''s got the basic requirements of even amounts of bits and bytes and no visual pattern.

Honestly, I think it will show tons of bit patterns. A gaussian bit noise is just the beginning. In the form it is right now, it''s just too simple. You don''t do any bit shifting nor hashing/permutations. Those are two fundamental standard requirements for PRNGs. You rely 100% on wrap-around ''randomness''. The standard C rand() function is very similar to that. But well, it all depends on what level of security you are heading for. It surely is a great algorithm to encrypt eg. TGA textures, so that people do not tamper them easily. And it''s very fast, so that you could do realtime en/decryption. But those kind of overflow algorithms tend to be breakable in no time by professionals. So, if you want to sell it to the NSA, it will need some further improvements

Have a look at the link I gave somewhere above, they have tons of (proven) symetric cipher algorithms there. You could have a look at their algorithms, could give you some ideas to improve your own.

- AH

##### Share on other sites
KalvinB    102
Here''s a bit pattern check for 1,2,3,4,5,6,7 and 8 bits.

Inverse bit patterns match pretty well in terms of occuraces. For example with the 2 bit pattern check

00 69482
10 103996
01 103995
11 69535

The program can do up to 4096 bit patterns but it took about a half hour to do a 416000bit file with just going up to 8bits.

Maybe I''ll leave it running for a couple days to check the key for patterns. The above file is an examination of an encrypted file.

Ben

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

##### Share on other sites
EvilCrap    134
destroying information before u encrypt data can greatly reduce required complexity of encryption algorithms, therefore reducing overhead associated with decrypting.

##### Share on other sites
Shannon Barber    1681
^ But the information is destroyed, so the cypher is useless.

quote:

any noise pattern combined with another *unrelated* noise pattern

Are not ''orthogonal'' noise patterns impossible?

...
It''s misleading to show the picture in false color. Change it to shades of grey and look it. The second one is much better than the first, but there''s still a visible pattern. It''s pretty good for how simple and fast the cypher is.

A simple test is to see how well a lossless compressor does on the encrypted data. A good cypher will produce a data that will become _larger_ when compression is attmepted.

I think I have to agree that buying a heavy-weight college text would get you alot further and alot faster than playing around.

At least you''ll get advice from someone who''s worked with it alot