This is not meant to offer protection, but if you want to say hide text by disguising it, then using Xor for reversible encryption will do the trick. It relies on the principle that if you Xor A and B to get C then you can Xor C and A to get B or Xor C and B to get A.
I wrote a short program and tutorials to demonstrate taking a single bit of text then disguising it. To make it more challenging, I only used Xor values from the range 0-255 that had four or more bits with 1 in it, for example 15 which is 00001111 in binary.
You can find the tutorial How to do Xor encryption in C. Please note this is only a very light weight encryption method so don’t use it for anything too important!
This is a little bit off-topic for this blog but hey it’s my blog and it is C code and I will be publishing it in full. It’s often said that programmers should not write their own encryption software because most programmers do not have the mathematical background. And I confess that’s me…
However, I thought I’d publish it and put it out there and someone can look at it and say, oh that’s far too easy to break, or maybe not!
The other truism with writing encryption software is that it must not depend upon the algorithm being concealed; the key yes, the algorithm no. So here’s my algorithm.
Generate a 64 byte key. This key has one property, in that it contains each of the 64 numbers 0-63. The order is scrambled. So it might start 0,1,2 but after the bytes have been shuffled (like shuffling cards in a deck) then it might have 43,9,12 and so on. Think of it as a single row with 64 columns. This 64 byte array must be written to disk. It’s a symmetric cipher, the same key is used to encrypt and decrypt.
Take the plain text and process it in blocks of 8 bytes at a time. Split those 8 bytes into 64 individual bits and write each bit to its own stream. So after processing 64 bytes, each stream has a single byte. Now write these 64 bytes to the file but index the column by the key i.e.
for (i=0;i<64;i++)
write(file, data[key[i]]);
So the first byte written would be data[43] then data[9], data[12] and so on.
So you say, that doesn’t sound very complicated. Are you sure it is encrypted?
Well consider our 64 byte key. There are 64! different ways of rearranging the 64 bytes. If I repeat some of my post from three days ago. “If you could do a million a second, it would take you 1.27×1083 seconds or 4.02×1075 years! Or to make it more meaningful it’s this large! 4.02,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years. That’s approaching (but still far far off) the time for the heat death of the universe which is estimated at 10100!”
Now I don’t know what methods might be used to crack it. Plus if you have some super-dooper fast hardware that can brute force it, it must have some way of recognising that the decrypted data is correct. If before encrypting it, we do a round of obscuring text, maybe something as simple as xoring the text with a repeating set of values, it’s going to make things a wee bit harder.
I welcome any comments on this and as soon as I have finished testing my program, I’ll put the source code up on Github.
