• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lastlinkx

PinWheel Encryption

20 posts in this topic

I am not any expert in cryptography either, but I just want to toss in an immediate thought I have from looking at the resulted encryption from the original pictures.

 

If you can see patterns and average colours or other hints in the result, then you are giving away information that can indicate weaknesses in your algorithm.

 

For instance: intuitively it seems like you can sort of do an average on colour values and get the same average as you have on the original picture.  On the picture with geometric figures, you can see lots of lines.  While it is not obvious what it is supposed to be in the encrypted versions of the pictures, it gives away information that can help in determining your algorithm to attack your encryption.

 

I can tell from the white noise picture that you are dealing with a black and white picture for instance.

 

I might be wrong about my assumptions, but it does give me a starting point as to figuring out your algorithm.  To me it sounds like The Comet's suggestion is a better one, or even generate a random seed from your password, and xor a random sequence from that seed over the picture.  To decode, just generate the same random seed and run the same random values and you will have the original data. 

 

No need to say that all these suggestions are really weak encryption methods, since it is easy to break as long as you have the algorithm.  I have a feeling the same goes for your spinwheel algorithm too.

 

A small note to what "TheComet" said, that you could obfuscate a little bit to make things harder.  While that is true, obfuscating doesn't really do much to secure your data.  It is better to have a proper encryption scheme right from the start.  Read about congruences and products of massively large prime numbers to do proper encryption or use a library if you want really solid encryption.  It is advanced, but there are examples that are easy to follow how to do this with examples using small prime numbers.  The technique is the same as in "proper" encryption, but you won't achieve really good encryption unless you use massively large prime numbers.

 

Security in today's encryption algorithms lie in the fact that it is hard to find the factors from a composite number from two massively big prime numbers.  If you can find a way to factor such numbers quickly, you will render almost all encryption methods useless.  

 

EDIT: Having a second look at your images, I see that my assumptions are not entirely right, but my point is still true:  the result should look entirely random, with no patterns or colour-similarities or other hints at all.  Just pure random data.

Edited by aregee
1

Share this post


Link to post
Share on other sites

What the above posters are saying is true. The least you should expect from an encryption algorithm is that the output should be indistinguishable from random noise.

 

Of course, having the output indistinguishable from random noise is not a guarantee of a secure algorithm, but the reverse is a sure indicator that it is not a secure algorithm.

 

It's pretty much the most basic test you can do to an encryption algorithm, and this does not pass.

1

Share this post


Link to post
Share on other sites

Excellent, I wasn't expecting this much of a response. This is great smile.png

 

OK, so the way I see it, here are the main concerns:

  1. Hash The password!
  2. Why bother spinning the data?
  3. What are these patterns I see?
  4. Black and white!
  5. Correlation between password strength and quality.

So, in relative order:

 

1 : Yes! hashing the password would be a good idea. I could generate a large number ( lets call it X) of bytes from a password and then use this as the "key".

The question is how large should the hash be? It clearly should be larger than 12 bytes, 24 bytes maybe?

The number of possible combinations from spinning the data appears to be 256n where n is the number of characters in the key. Thus 25624 yeilds 6.27 x 1057 possible combinations. If we assume that a computer can evaluate 1 billion combinations per second, an attempt to try every single combination of 24 bytes, or brute force a password, could still take up to 1041 years.

 

2 : You guessed correctly when you said "to obfuscate the data." By performing these spins, a byte, or a variant there of, can end up literately anywhere within the block! On a smaller scale, a bit can end up anywhere within the block as-well, because remember we're rolling too! With 256 bytes, there are 2048 bits. There are, by definition, 2048! ways to organize 2048 bits, and by spinning and rolling we can achieve any of these combinations. In other-words, by spinning and rolling we set the maximum number of possibilities to 2048! or around 105895 possibilities.

 

The other reason to spin the blocks is to create multiple solutions, which sounds counter intuitive!

Just because you find a solution to a block, doesn't mean that it'll work for any other block.

So for example lets say that we have 256 bytes, where the first byte is 0 and the rest are 1. Next we have another 256 bytes where the last byte is 1 and the rest are 0. Finally we encrypt both of the data with the same password, say "boat", Now because we spun the data, there is a massive number of ways to spin the data in reverse to get the byte '1' back into the first slot, one of these ways is, obviously, to follow the pattern generated by the password "boat", however other pass-codes may work like say "hamburger" The trick is that even though the pass-code "hamburger" successfully decrypts the first set of 256 bytes, it WILL not decrypt the second set! Only the passcode "boat" will do that.

 

Furthermore, even if you had the original as well as the encrypted version of a file, you would still need to try MANY ( up to  25624 ) combinations of passcodes to find the one that works for every block and crack the password.

 

3 : Ah yes the patterns in the triangles... maybe I should have been more specific in my captions.

Of course there will be patterns, this is a worse case scenario test. The data in that image is LARGELY repetitive, in fact each row of 256 pixels, the width of the image, is usually close to identical to the row above it. Encrypting blocks that only have a 1 byte difference between one and another will unfortunately yield somewhat similar results. This effect is compounded by the fact that the change between rows is fairly regular. If I reduce the size of the image to 246 x 246 pixels and then encrypt with an 8 char password, we get this:

 Colors246-M_zpsa8ed693c.png

Which while not perfect, you can still somewhat see the triangles, looks more like noise.

 

To spice things up, and prevent these types of patterns, the amount of roll could be varied. Part of the issue is that most ASCII pass-codes limit the amount of roll as the high bit is usually 0.

 

4 : This one is kind of silly. It's black and white because it's a black and white bitmap! - Remember I only encrypted the image/data portion of each bitmap. No amount of encryption is going to change the fact that in a grayscale bitmap, each pixel is determined by one and only byte and must be somewhere between black and white.

Here's what it would have looked like, had it not been grayscale, but 24bpp (COLOR) with an 8 char password :

FlowerC2_zpsdbebc496.png

 

5 : The correlation between password length and quality was actually intentional. I figured that longer passwords yielding better encryption was ideal. After reading some of the feedback I've gotten, I now know this to be false. By hashing the passcodes ( See # 1 ) we can remove this correlation.

 

Sorry if my explanations haven't been the best.

 

Again, thank you everybody who has spoken thus far. Any other ideas and comments would be appreciated.

Edited by LarryKing
0

Share this post


Link to post
Share on other sites

Sorry to go a little off topic here, but isn't there a flaw in the way 7zip encrypts its data?

 

DOjY5.png

 

If the program knows the password is incorrect [i]before[/i] decrypting and decompressing the data, then it means the hashed password is easily accessible - perhaps in the file header? Shouldn't the data be decrypted and decompressed regardless if the password is correct or not, the only difference being an incorrect password will produce a huge pile of garbage? Can someone explain this?

0

Share this post


Link to post
Share on other sites

If the program knows the password is incorrect before decrypting and decompressing the data, then it means the hashed password is easily accessible - perhaps in the file header? Shouldn't the data be decrypted and decompressed regardless if the password is correct or not, the only difference being an incorrect password will produce a huge pile of garbage? Can someone explain this?

 

Sure, the hashed password is available. But you can't use it for decryption. Basically it goes like this:



    +----------------------------------------------+              +-------------------------------+
    |                                              | ONE WAY ONLY |                               |
    | Plain password (typed by the user)           | +----------> | Encryption key                |
    |                                              |              |                               |
    +----------------------------------------------+              +-------------------------------+
                          +
                          |
                          | ONE WAY ONLY
                          |
                          |
                          v
    +----------------------------------------------+
    |                                              |
    | Hashed password (useful only for comparison) |
    |                                              |
    +----------------------------------------------+

The two are unrelated and you can't deduce one from the other. So the hashed password is used to find out if you typed the right password, and then when you did, the program can calculate the encryption key and decrypt the program. That way it can warn you if you typed the wrong password without decrypting garbage, without any security issues. So technically the hashed password isn't "needed", it's a quality of life thing to guarantee that you don't end up decrypting garbage, and also lets you check the key *without* decrypting anything (which is relevant in some cases).

 

You can also do more advanced stuff with this such as making sure the file was not compromised (modified surreptitiously) etc.. basically it's a useful technique, and does not indicate a security flaw smile.png

2

Share this post


Link to post
Share on other sites

So, I've made a few changes that seem to fix the two biggest issues:

I've introduced a "Turbulence" phase to combat patterns,

and I've also added an "Avalanche" phase to increase sensitivity:

 

The results:

A difference of a single bit will result in dramatic variation.

 

Small test: A 256 byte file was created with all bytes = 0xFF and a second, similar file was created where all bytes = 0xFF except for the last byte which = 0xFE

 

Here are the visualizations of the two files: (Note they are 16 x 16 pixels and are quite difficult to see on a white background)

File A : wbmp_zps08624d9f.png

File B : wpbmp_zpsc6f1c551.png

 

Both files were encrypted using the same passcode:

Result A : wbmp1_zpsf36db3db.png

Result B : wpbmp1_zps69c1ebcf.png

 

Both results appear as noise; however each is different.

 

And finally we have the "worst case scenario" triangle image/data test:

ColorsV2_zpsf6e1642f.png

 

Please note that the vertical lines are the result of blocks of data being EXACTLY the same in the original data.

As in one row of pixels being exactly the same as another:

ColorsLines_zps13d663bf.png

Note: Each row of pixels in the solid green block is exactly the same, as is the case wherever else there are vertical lines; encrypting identical datas returns identical results.

In other words, please don't point out the "clear pattern of vertical lines" smile.png

 

Now, adding both the turbulence and avalanche phases to the algorithm results in a ~ 40% increase in computation time.

 

The new code is attached ( PNWL.h )

 

Also, I'm still looking for a good passcode hashing function.

If you feel like testing the new algorithm, use a longer password, or better yet, to emulate a hashcode, generate a 24 byte null terminated string  randomly and use that.

 

Again thank you.

 

Edit: Forgot to attach the new code XD

Edited by LarryKing
0

Share this post


Link to post
Share on other sites

encrypting identical datas returns identical results.

 

Well, i know you asked not to point it out, buuut... i think that's the biggest flaw in your algorithm. Encrypting identical data should NOT return identical value...

 

Anyway, i guess that code is just for your personal usage so, who care. No one is probably gonna try to break your code, unless you ask them to.

Imo that's good enough for personal use.

 

My first encryptor was showing a similar flaw (you could see parts of a bitmap image in the noisy background), then i just created another algorithm, which isn't perfect, but at least give no clue as in your image, everything always look 100% noisy, but even then, ppl started pointing flaws about it. (You definitely should read this post)

 

For me, i guess that just good enough for my need, althrough i never used it yet for anything, it was more for learning than anything else.

For the fun of it, i encrypted your image using my algo. discussed above, and it gave me this. That's what you should aim.

 

PS: dont take me too seriously, im no encryption expert...

Edited by Vortez
1

Share this post


Link to post
Share on other sites


By performing these spins, a byte, or a variant there of, can end up literately anywhere within the block! On a smaller scale, a bit can end up anywhere within the block as-well, because remember we're rolling too!

There is the problem, it is not enough if the set of all passwords allows any bit to appear anywhere. You would need to make sure that for a single password the bits are shuffled around enough that they can be anywhere, but as can be seen from your pictures thats not happening. I would think that is because of an inherent flaw of your pinwheel thing, that moves the bits in a very predictable way that mostly depends on the source data and not much on the password.

And you know, xor obfuscation is the first thing everyone tries, but cause of its property of revealing a source bit by double xor-ing it with the same bit it will never make a good encryption in that way you use it, even if your method is a bit more elaborate than usually seen.

0

Share this post


Link to post
Share on other sites

its property of revealing a source bit by double xor-ing it with the same bit it will never make a good encryption in that way you use it

 

How does it reveal a source bit if you only have the XORd bit?

0

Share this post


Link to post
Share on other sites

 


encrypting identical datas returns identical results.

 

Well, i know you asked not to point it out, buuut... i think that's the biggest flaw in your algorithm. Encrypting identical data should NOT return identical value...

 

Anyway, i guess that code is just for your personal usage so, who care. No one is probably gonna try to break your code, unless you ask them to.

Imo that's good enough for personal use.

 

My first encryptor was showing a similar flaw (you could see parts of a bitmap image in the noisy background), then i just created another algorithm, which isn't perfect, but at least give no clue as in your image, everything always look 100% noisy, but even then, ppl started pointing flaws about it. (You definitely should read this post)

 

For me, i guess that just good enough for my need, althrough i never used it yet for anything, it was more for learning than anything else.

For the fun of it, i encrypted your image using my algo. discussed above, and it gave me this. That's what you should aim.

 

PS: dont take me too seriously, im no encryption expert...

 

 

 

What I'm trying to say is that for a set of inputs - the passcode being X and the 256 byte block being  Y - the algorithm should satisfy the requirements of a "function" : for a given set of inputs the function should return a specific output

F(x, y) == z always

 

If two blocks are identical, Y1 == Y2, and they are being encrypted with the same pass code, then F(X, Y1) == F(X, Y2) == some value z

Our ability to decrypt the data, given the correct passcode, relies on this fact.

 

Now if I wanted two identical blocks encrypted using the same passcode to not return equivalent values, I would need to add another "variable" to the function.

So If I added the block's number as variable W so,

F(w, x, y) == z

then two identical blocks, being encrypted with the same pass code would not give identical results.

I tried this and the results were promising :

 

ColorsT1_zps16f4ee46.png

 

However, I decided that the algorithm shouldn't care or know which block it was dealing with, as an "attacker" could easily later determine this "variable" and use it to weaken the integrity of the system

 

I'd rather have only two inputs X and Y that can't be determined by looking at the encrypted data, than

three variable W, X and Y, where one of the variables could be determined.

 

 


By performing these spins, a byte, or a variant there of, can end up literately anywhere within the block! On a smaller scale, a bit can end up anywhere within the block as-well, because remember we're rolling too!

There is the problem, it is not enough if the set of all passwords allows any bit to appear anywhere. You would need to make sure that for a single password the bits are shuffled around enough that they can be anywhere, but as can be seen from your pictures thats not happening. I would think that is because of an inherent flaw of your pinwheel thing, that moves the bits in a very predictable way that mostly depends on the source data and not much on the password.

And you know, xor obfuscation is the first thing everyone tries, but cause of its property of revealing a source bit by double xor-ing it with the same bit it will never make a good encryption in that way you use it, even if your method is a bit more elaborate than usually seen.

 

 

A bit can take multiple paths to end up in the same spot. By taking these alternative paths though, the other 2047 bits also take alternative paths.

 

The movement, or spinning if you will, is determined only by the passcode, and there is only one combination of spins, only one passcode, that will decrypt all of the blocks.

Even if you know that the data was "spun", you don't know which path it took.

I imagine this path on a massive tree where each branch has 256 child branches, and each of those child branches has 256 child branches and so on.

The number of unique combination for a given password length n is 256n where hopefully n is some large number like 24

 

Also, there is more than XOR'ing going on, there is twisting, turning, and in the newer version, turbulence ( noise ) being added to the mix.

To decrypt, each byte must not only be XOR'd with every byte it had been, which would have to determined some how, but it must do so in the correct order as other operations such as rolling and the turbulence take place. In other words, you must follow your exact path up the tree to retrieve the original data.

 

Yes, this is only a pet-project, so it's not likely anyone other than myself will ever use it.

Still, I'm happy to see other people's ideas.

Edited by LarryKing
0

Share this post


Link to post
Share on other sites

If a is a point in the above picture with the triangles, then there is a high chance its rotated and xored twice (or any multiple of 2 times) with the same color from one of the big same colored areas, then you have a as "encrypted" data although its actually not. (There are a few other things happening and then it results in those stripes.)

0

Share this post


Link to post
Share on other sites

If a is a point in the above picture with the triangles, then there is a high chance its rotated and xored twice (or any multiple of 2 times) with the same color from one of the big same colored areas, then you have a as "encrypted" data although its actually not. (There are a few other things happening and then it results in those stripes.)

 

Impossible, each block is processed independently.

I think I wasn't clear in my description of what a block is.

A block is 256 bytes; the picture divided into 9 areas, does not show 9 blocks, but rather 768.

 

Maybe this will help with my explanation of what a "block" is

 

Scan_zps77ef1654.jpg

 

*Pretend I was able to draw 768 lines ( which each represent a block )

 

Sorry if I've been a bit hard to understand, my mind is focused on Thanksgiving

 

But, in the case where data is divided as such, and each block is independently encrypted, does this make sense?

0

Share this post


Link to post
Share on other sites

 

(a xor x) xor x == a


Yeah but you don't have "a", you only have the encrypted data...

 

 

This situation is not so far fetched, if you just XOR password with data:

Source data:            010203040506000000000000000001020304050
Password: (XOR)         70617373776f726470617373776f72647061737  (password repeated over and over)
Result: (XOR-encrypted) 71637077726a726470617373776f73667365727
Similarities:           7 6 7 7 7 6 726470617373776f7 6 7 6 7 7
Oops, password in clear text:       r d p a s s w o

So if you are going to use an encryption algorithm based on XOR, you need proper "random" data to XOR with.  Anything else will be exposed.

 

EDIT: (But I probably misunderstood your question, as I saw you already got your answer.)

Edited by aregee
0

Share this post


Link to post
Share on other sites

[background=#fafbfc]So if you are going to use an encryption algorithm based on XOR, you need proper "random" data to XOR with.  Anything else will be exposed.[/background][/size]

 
That's why I suggested to combine it with compression (and hash the password). Something as simple as run length encoding (RLE) will be sufficient already, it will eliminate any trailing numbers and make it impossible to extract the password. Edited by TheComet
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0