I developed Pivot initially on Windows, (a Linux version will follow) though the differences are fairly small. I used the Windows _sopen_s for reading and writing files. There shouldn’t be too much differen otherwise, though I guess I’ll find out when I compile it on Ubuntu or Raspberry Pi.
The program itself is around 450 lines of C in just one file. It can encrypt around 6 MB/s on my five year old i7 5930K PC and decrypt at around 10 MB/s.
If anyone could try this, I’d be very happy. It has one minor issue that I will resolve. Because it processes files in blocks of 64 bytes, it tends to round the output file when decrypting and adds a few 0s on the end. I will get it sorted
I’ve given it a very liberal MIT license, you can do what you want with it. Instructions on using it are provided on that link to GitHub.
This BTW is the encryption code at the heart of it.
int bit = 128;
for (int bi = 0; bi < 8; bi++) {
for (int b = 0; b < NUMSTREAMS; b++) {
dataout[b] = (dataout[b] >> 1) | (data[b] & bit);
data[b] <<= 1;
}
}
// Now alter the order of bytes according to the key
for (int i = 0; i < NUMSTREAMS; i++) {
data[i] = dataout[_key[i]];
}The first double for loop slices 64 bytes into 64 bit streams. It’s pivoting the bits if you like, hence the name. The second for loop is what does the donkey work of encrypting it. It uses a 64 byte key (made up of 64 numbers 0-63- shuffled). As there are 1.2688693e+89 different ways of arranging these 64 numbers, if you lose the key it might take you a while to brute force it!
So I believe that it is an original encryption algorithm, but I am not an expert in cryptography so I might be making a fool of myself! Whether there are any possible attacks against it, I don’t know, but it will be interesting to see!
This is an interesting algorithm but definitely not secure (but still interesting!). I’m only an amateur myself but there are probably many ways that one could approach cracking this without brute force. An attacker would only need to guess at likely plaintext (whether it’s actual text or even binary data) contained in the streams. You would rearrange the bits to form the hypothesized plaintext and then use that permutation on the other streams encrypted with the same key to see if additional plaintext patterns emerge. Cracking the key actually becomes exponentially easier as you make progress because you can infer further plaintext from what’s already been revealed, almost like solving a jigsaw puzzle that doesn’t have a reference picture.
Guessing at initial plaintext might be difficult for a novice but an accomplished cryptographer will have an entire corpus of patterns for various file formats to test, not unlike a definition database used by antivirus software. Also, it wasn’t entirely clear how you were handling the padding at the end but if it’s just a string of 0’s, that’s going to be an attack surface which drastically reduces the key space.
Feel free to send me an email if you ever want to chat about cryptography!