It has been a while since I posted so here is an update for you guys. I should (hopefully) have some time to post some more blog posts detailing my current projects over the next week or so.
My image encryption tool (now known as PGIE – Pretty Good Image Encryption) is finally completed. Anyone wishing to test it is welcome to ask me about it.
Here is a little description that I threw together about the program.
Have you ever had a secret you wanted to hide in plain sight while still feeling secure? If so PGIE is just the program for you!
PGIE uses an innovative and unique mix of new and traditional encryption techniques to store data within a randomly generated pixel image that can only be decoded using a special key file.
How It Works:
PGIE first encrypts the data using a Rijndael symmetric algorithm. The key used to encrypt the data is a randomly generated 1024-bit binary key that is unique to each encode.
The encrypted data is then split into sections and stored within the image. The data is then further secured by modifying the file based on the information stored within the key file. Finally the image is modified to make the original entry point unreadable.
If either the key file or encoded images are modified or damaged then the encryption is one way.
In order for a brute force attack to be successful on this encryption the whole key file image would have to be guessed precisely; every red, green, blue and alpha component would have to match the original in order for the decryption to occur successfully. This would take a very, very long time to achieve with modern computers. See the technical details section below.
There are a set of 65,535 possible characters that can be used in the encryption key and the key is 1024 characters in length. This means that there are 65535^1024 possible key sets to choose from – one very large number! In the simplest terms possible – if a computer can generate a billion keys per second then it would take far, far longer than the universe has existed to forcibly break.
There are four channels for data within a PNG pixel, red, green, blue and alpha. Each of these can range in value from 0-255. That means that there are 256^4 possible colour values per pixel (4,294,967,296). As the image size grows more pixels need to be correctly guessed in order to decode the image. As such each added pixel makes the image more difficult to decode again, making it virtually impossible to forcibly break.
Just a quick update. Firstly happy new year since this is my first post for this year.
I’m currently working on a new site that will give Neopets users some interesting new tools to play with. I will post more details about it as I decide what features will be there – but in the mean time any suggestions and requests are welcome.
I will be focusing much of my efforts on statistic related items – trying to determine how the random events and so fourth work.
Here I am, writing about yet another one of my projects. This time I have decided to work on a program relating to a subject that is both close to my heart and one that some people find difficult to understand – chemistry.
I am thus building a tool to help people understand and solve chemistry related issues, it comes with a periodic table (as shown below) a chemistry calculator as well as some other features. As always I am open to suggestions and help should you wish to contribute either.
I will post developments on this project as I complete or start work on various parts of it so stay tuned for more! (Yes, I did copy the colours from the Wikipedia Periodic Table but I am colour blind so that was the best I could do under the circumstances!)
In an earlier post I said I would explain a little about the the format used in my new data encoder and so here it is.
The images are stored in PNG, not any other type of format, because PNG supports full alpha transparency. The data is encoded by converting the text into binary data and then these are converted into pixels of colour, with the data stored in one of the 4 colour components (red, green, blue, alpha).
Certain operations are then done on this data to make it harder to recover and the remaining spaces are filled in with randomly generated pixels.
I am pleased to announce that the new image encryption tool I was working on is now completed, boasting some new features that I will post about later. I also hope to post about the format, and how the data is stored (though I will keep some of the details hidden to ensure the format remains secure). If anyone wishes to beta test the software then please context me.
But for now I am going to get some much deserved rest. Keep an eye here for more information soon.
Since I now have some more spare time I have been working on a new tool that allows you to securely hide at most 4 pieces of information (each a maximum of 255 characters in length) inside a random pixel image. I am working on ways to use this technique inside real images, but that is somewhat more difficult and it may take a while to perfect, if it works at all.
The image appears to be a random pixel generated image with varying colours, usually with 50×50 pixels in dimension (but this is not required to be so). The image looks something like this:
… And when you open it in the decoder tool you get something like this:
The program is actually quite simple but the way in which the information is stored should make it quite difficult to break. However with the decoding tool I have designed, you need only open the image to retrieve the information. If anyone is interested in hearing more or has some ideas to contribute, please let me know. I will release more information about the system used and so on at a later time when I stabilize the idea and format.
Network information is a complex subject at the best of times and simplifying it for the average user is no simple feat. Even harder it seems is actually writing code to get this information programatically! I was quite disappointed to find that there was no simple way to get an IP address via code – mainly since Windows does not actually know it until a request is made. I eventually made a work around and used a web script to scrape the information. It saved a lot of time and effort in the end.
Getting the internal IP address was also quite interesting. It involved using some built-in .NET code. The only issue is that there were nearly always IPv6 addresses returned first. Since these are not well known (yet) I decided to list only the IPv4 address instead. The code I came up with is listed below – hopefully it will help someone else.
IPHostEntry localIPAddresses = Dns.GetHostEntry(Dns.GetHostName());
string localIP = (from ip in localIPAddresses.AddressList where (ip.AddressFamily == AddressFamily.InterNetwork) select ip).First().ToString();
As you can see I also use LINQ there instead of a foreach loop since I find it much more readable. I am nearly finished with the main basic info page now so pretty soon I will have some new screen shots to demonstrate the new design of CSIT!
It has been a busy week so I have not had much time to blog about my work and activities. Due to developments it seems the CoalFields funding for CCC will not be available in July as hoped – probably not until September or October. That is a pity but it will not stop us moving forward.
But! That is not why I am blogging today – I am here today to discuss some work I have been doing on the CSIT main interface.
After much deliberations between myself and Ashley Vaughan we argued the idea to the following interface style.
The design is simple, clean and should be easy to modify in the future. As you can see there are tabs dividing hardware and software (and there may be others there too). Next on the left of each tab there are the categories found under expanders. These will be made into accordion-style items eventually though I think it is more important to get the program working first. Finally on the right are the tabs containing the information from the selected category.
It was quite difficult deciding on one design since there were so many to choose from.
As always, any comments or suggestions relating to the design please post or contact me.
I am pleased to report that I have finally made some decent progress with CSIT. I now have the pinvoke links completed and functioning, I can also get access to the features that a CPU supports as well as information about the caches and other information about the CPU – yay!
Below is a screenshot showing some of the information that I have succeeded in extracting from the deep code calls.
Looks simple doesn’t it? Well. You probably wouldn’t believe it but the framework code written to reach this point has just passed fourthousand lines!
If anyone has any comments or suggestions about other features that should be included or improved then please let me know! However please note that this is nowhere near completed and these are just testing features. I have lots more planned yet!