[ArkPhaze]

So finally this prolonged project is in it's first complete stage if I wish to continue development on this.

Name: BitCrypt
Description: Visually encrypt binary data from an input file over to a Bitmap format, and decrypt it at a later date.

Video:
*This was my first working beta preview, current version on my computer is more optimized for performance and speed.*




Example Encrypted Output BMP 24::


Another example:


Haven't added compression to this yet or anything. The original BMP files I had were too big to be uploaded. I compressed relatively larger files as these examples, then these are also reduced in scale.

[Frooxius]

Does it actually do any encryption of the data or do you simply transform each three bytes of the input data to a RGB pixel (in case of RGB888)? I mean, if I see such noise picture, it immediately strikes me that it's some binary data and if you don't do any actual encrypting, then it's very simple to get the original data, as it doesn't really tamper them anyhow, only transforms their form by wrapping them into a picture. What's the point of using pictures anyway, why not just write an actual encryption/decryption algorithm, this just a little bit of unnecessary bloat data.

Pictures make sense if you use them for steganography, which conceals the data. In fact, unless it does any real encryption, I would call this very weak steganography method. Normally you would take an existing, regular, suspicion-less picture and hide the data in the LSB of the pixels, so it wouldn't be apparent that there are any underlying data hidden. This however, is still not an encryption, it's steganography, it doesn't protect the data itself from reading, but rather hides their presence in certain way, so it's usually good to combine steganography with encryption.

[ArkPhaze]

Does it actually do any encryption of the data or do you simply transform each three bytes of the input data to a RGB pixel (in case of RGB888)? I mean, if I see such noise picture, it immediately strikes me that it's some binary data and if you don't do any actual encrypting, then it's very simple to get the original data, as it doesn't really tamper them anyhow, only transforms their form by wrapping them into a picture. What's the point of using pictures anyway, why not just write an actual encryption/decryption algorithm, this just a little bit of unnecessary bloat data.

Pictures make sense if you use them for steganography, which conceals the data. In fact, unless it does any real encryption, I would call this very weak steganography method. Normally you would take an existing, regular, suspicion-less picture and hide the data in the LSB of the pixels, so it wouldn't be apparent that there are any underlying data hidden. This however, is still not an encryption, it's steganography, it doesn't protect the data itself from reading, but rather hides their presence in certain way, so it's usually good to combine steganography with encryption.

Not yet, that was the plan eventually so i'm keeping it in the title as "Encryption" What will happen is encryption and compression after the fact. Then reversely decompression, and decryption, back to a filestream to be wrote for the original data retrieval.

What's the point of using pictures anyway, why not just write an actual encryption/decryption algorithm, this just a little bit of unnecessary bloat data.

You've never heard of being unique or doing something for fun?...

Pictures make sense if you use them for steganography, which conceals the data. In fact, unless it does any real encryption, I would call this very weak steganography method

That's good to know Where did I throw around the word stenography? You think you can assume that was my intention?

I could hide stuff behind regular image files, but that wasn't the point, I wanted to show some of the "encrypted" data through the form of pixels in a bitmap by the time I complete this project in full if I continue to improve on this and finish it to the end.

[Frooxius]

PhazeShift: I think I sense a bit hostile tone from you, if that's the case, I would like to ask you to refrain from doing that please, there's no need to cause drama.

Not yet, that was the plan eventually so i'm keeping it in the title as "Encryption" What will happen is encryption and compression after the fact. Then reversely decompression, and decryption, back to a filestream to be wrote for the original data retrieval.

Yes, but right now it doesn't seem like an Encryption and your post haven't stated that you intend to add encryption in the future, so I was only asking based on what information you gave. It even says "visually encrypt", which seems to imply that it's somehow "encrypted" by transforming into visual form. You only mentioned compression. So you'll be doing basically three more or less independent parts: encryption, compression and wrapping the data to a bitmap, right?

You've never heard of being unique or doing something for fun?...

I've created a Lossy Text Compression algorithm, or even experimental processor architectures (WPU) for fun and to make something unique, so I would believe the answer is yes. I have nothing against that, I was just asking...
That being said, I don't think this is very unique though, as it has been done before (it's just trivial data transformation), for example to encode raw sound data, apply an effect in image editor and convert back to sound. But if it's fun for you, I'm not stopping you, you could've just said so.

That's good to know Where did I throw around the word stenography? You think you can assume that was my intention?

I could hide stuff behind regular image files, but that wasn't the point, I wanted to show some of the "encrypted" data through the form of pixels in a bitmap by the time I complete this project in full if I continue to improve on this and finish it to the end.

And where did I say you threw that word around? I never claimed that it's what you've intended or anything like that, I simply mentioned a case where images are used for a specific type of data protection, nothing more, nothing less.

[ArkPhaze]

PhazeShift: I think I sense a bit hostile tone from you, if that's the case, I would like to ask you to refrain from doing that please, there's no need to cause drama.

Not yet, that was the plan eventually so i'm keeping it in the title as "Encryption" What will happen is encryption and compression after the fact. Then reversely decompression, and decryption, back to a filestream to be wrote for the original data retrieval.

Yes, but right now it doesn't seem like an Encryption and your post haven't stated that you intend to add encryption in the future, so I was only asking based on what information you gave. It even says "visually encrypt", which seems to imply that it's somehow "encrypted" by transforming into visual form. You only mentioned compression. So you'll be doing basically three more or less independent parts: encryption, compression and wrapping the data to a bitmap, right?

You've never heard of being unique or doing something for fun?...

I've created a Lossy Text Compression algorithm, or even experimental processor architectures (WPU) for fun and to make something unique, so I would believe the answer is yes. I have nothing against that, I was just asking...
That being said, I don't think this is very unique though, as it has been done before (it's just trivial data transformation), for example to encode raw sound data, apply an effect in image editor and convert back to sound. But if it's fun for you, I'm not stopping you, you could've just said so.

That's good to know Where did I throw around the word stenography? You think you can assume that was my intention?

I could hide stuff behind regular image files, but that wasn't the point, I wanted to show some of the "encrypted" data through the form of pixels in a bitmap by the time I complete this project in full if I continue to improve on this and finish it to the end.

And where did I say you threw that word around? I never claimed that it's what you've intended or anything like that, I simply mentioned a case where images are used for a specific type of data protection, nothing more, nothing less.

Okay... Well thankyou for understanding, as soon as I seen the first reply from you, regardless of what I was going to respond I started thinking "Oh.. here we go again, another long debate with this guy.."

There's hardly much that isn't already done in programming, unless you're really thinking outside of the box so to speak. I haven't seen everything, so I can't always be accurate if I was to say that I was the only person to do it.

When's the last time this forum had been posted in though? So I shared one of my projects from a while back. Only just completed it a few weeks ago though because I was unsure of what I was going to do with it. It started out as an idea.

[bluedog.tar.gz]

I think this actually is a pretty fun idea.
But i've got a question, do files always come out random or is there an algorithm?

[Frooxius]

I think there's still a lot that can be done in computer sciences (which is more than just programming), though it's usually not something trivial.

I'm not saying to not do it or anything, just asking questions and mentioning some related things, but I never stated to not post it or not do it or anything like that, only to clarify things. If I wanted to say to not post something or not do something, I would state so directly, which I don't do often, unless something can be really bad and hurt someone for example.

Are you going to design your own algorithms for compression and encryption, or use existing ones? Like LZMA for example, it's opensource.

bluedog.tar.gz: Well obviously there's an algorithm, since you would be unable to get the original data back if you used some randomness generator to make the pictures. I'm not 100 % sure, but it seems like simple transformation. Each pixel in 24-bit RGB picture is composed from... well 24-bits, which are 3 bytes, so you simply take three bytes from the input file and make it a pixel and so on, for each pixel. Of course you have to pick right size so you don't waste any pixels. The reverse process is simple too - "decode" each pixel into three bytes (it already is three bytes, so it's more like copying). Of course there are more variations, depending on the output image format (mostly bit depth) or how you want to arrange data in the picture.

[ArkPhaze]

I think there's still a lot that can be done in computer sciences (which is more than just programming), though it's usually not something trivial.

I'm not saying to not do it or anything, just asking questions and mentioning some related things, but I never stated to not post it or not do it or anything like that, only to clarify things. If I wanted to say to not post something or not do something, I would state so directly, which I don't do often, unless something can be really bad and hurt someone for example.

Are you going to design your own algorithms for compression and encryption, or use existing ones? Like LZMA for example, it's opensource.

bluedog.tar.gz: Well obviously there's an algorithm, since you would be unable to get the original data back if you used some randomness generator to make the pictures. I'm not 100 % sure, but it seems like simple transformation. Each pixel in 24-bit RGB picture is composed from... well 24-bits, which are 3 bytes, so you simply take three bytes from the input file and make it a pixel and so on, for each pixel. Of course you have to pick right size so you don't waste any pixels. The reverse process is simple too - "decode" each pixel into three bytes (it already is three bytes, so it's more like copying). Of course there are more variations, depending on the output image format (mostly bit depth) or how you want to arrange data in the picture.

Trying to show some tact in my posts here. I agree.

Everytime there's inspiration that sparks from ideas that people pursue, there's that possibility. Since this was a for fun project, I may take on my own method of encryption, but for compression, if I wanted something simple, i'd just compress the bytes using the regular DEFLATE compression method used in most .zip archives before I actually convert to BMP. No need for much of anything fancy. If the data is encrypted, all i'm worried about from that point on is the output filesize.

Any suggestions you have? Since this is an improvised project, from ideas i've gained along the way, doesn't hurt to see what others think. So I guess criticize the program all you want for now.

Maybe my next update will improve it a bit more.

@bluedog.tar.gz - There's an algorithm, otherwise I wouldn't be able to decode back to the original file. Pretty straightforward algorithm at this point though honestly. Each color represented as a byte of the input data basically.

[1llusion]

I've once seen something similar, however, for malicious use.
I don't remember correctly how it was, but I think it was a malware, that had its payload inside a picture/icon.

Good luck with your project!

[Frooxius]

I have some suggestions.

Binary -> Bitmap positioning methods
What about trying to make the data transform algorithm more complex, to make the images more visually appealing/interesting, or even better: give the user an option to select the transform method.

You could play with various forms of binary -> bitmap transformation. For example provide several ways the data are placed as pixels. How does it work now? Is it simply filling it row after row? What about going in a "square" spiral, starting at the center? What about going zig-zag? Or diagonal?

Or make it pseudo-random - make a function that will randomly generate a pixel position in a way, that it will never use the same pixel more than once so if you have 1Mpx and you'll generate a series of 1 million positions, every one will be unique to cover the whole bitmap, that way the bytes will be seemingly randomly scattered around the picture, but if you use the same seed for randomization for decoding, you can get the same series of positions as well.

Binary -> Bitmap data pixel storage method
Right now, you're simply transforming three bytes of input data to a single RGB888 pixel (in case of RGB24) right? What about complicating the storage itself a bit?

For example, first store one third of the data in red channel, then green, then blue. Or take 8 pixels (8*3 = 24 bytes) and 24 bytes of input data and then take one bit from the first byte of the input data and store the bit in the first pixel. Then take second bit from the first byte of input data and store it in the second pixel and so on. Simply, don't put the whole input byte into a whole byte of one channel, but scatter the bits of the input byte among multiple pixels.

Binary -> Bitmap data encoding
What about not storing the bytes as they are, but for each pixel only storing a difference from the previous pixel? To show an example with a few numbers, imagine you have sequence:
45, 50, 20, 20, 20, 30, 40, 50
And you store the differences (the initial value can be zero for example, so the first number is difference from zero):
45, 5, -30, 0, 0, 10, 10, 10

Try more variants and more complicated encodings than just differences, of course it must be possible to calculate back the original data, the encoding must be reversible method.

You can try first calculating average value of all the data and then store difference from that and try to prevent sharp differences.

Binary -> Bitmap image key encrypting
An idea for actual encrypting - use some original arbitrary picture as a key - only store difference (for example, or XOR) from this picture, so it will be required for decoding as well. The picture will basically become a "password".

Using GIF
Instead of one large picture, generate a series of 8-bit bitmaps and then save them as an animated GIF. Since GIF already uses some compression, it might help to further compress the data. You can use it in combination with the above. You can generate a palette to make the images visually interesting or give user ability to generate a palette, for example using some color gradient.

Binary -> Bitmap pattern organizing
Try to arrange pixels into patterns, for example encode a chunk of data into a triangle using only red channel and overlay it with another pattern that uses green channel and the triangle pattern is shifted and so on. Maybe don't even bother about space that much and simply generate a block that will use only red channel, then another block that will use green, then another that will use green and red (maybe store the same value in both, making it yellow), to make a colorful pattern, rather than random "noise". It will waste some pixel data, but perhaps you could try lossless image compression handle that.

Binary -> Bitmap even more wasting
What about not using just a single pixel to encode a chunk of data, but using a larger chunk and visually stylizing it somehow, for example by making a smooth gradients to neighbouring colors. You can try storing some data only in lower bits of these gradient-transition pixels, for example in the lower two bits, to don't distort the color too much, but get some extra space, while making it look funky.

Compression - using lossless image compression for arbitrary data
Try compressing the resulting images with various lossless algorithms (such as PNG), using various transformation methods I mentioned and seeing the results, how effective it is for various types of data. Make some nice statistics and data from this.

Try using lossy (JPG for example) compression algorithm to compress the image, then calculate difference from the original and compress the difference using lossless algorithm, so you can use the two to reconstruct original data. Will their size combined be smaller than using just a lossless compression?

Library
Wrap it into a nice library that other can use in their software for various purposes. Such design allows you yourself to develop the algorithms independently and just develop a GUI on top of such library. It will allow to automate various tests I mentioned above.



I think that's enough for now, I think if you do all this, you could actually write a paper about it In fact, it's something I planned to do before, but put away, because I got other projects.