Just realized that you could easily brute force the below in checksum*scrambler key iterations, so without a large scrambler key, it's pretty weak ;o.
Anyways, that's something I'll hopefully address in the remake as well ^)^
So this is a description of the current algorithm I'm using
So I've been trying to update an encryption algorithm I'm currently using (example of output pastebin.com/pPtz9UYd) |
The algorithm is as follows.
Input a string like an account name and then add a salt value to it (salt value is like the password). Hash this result. Take the absolute value and convert to base 8, then add 1 to each digit. This is now a key.
Example key -> 19455
This key swaps digits. Given 1535395398 in base 10, if this key were applied to it, these are the steps that would be taken.
Input --> 1535395398
Output -> 1559333958
However, this does these swaps multiple times and in different bases. For example, if this same operation was done in base 2, the number would look much different. If this same operation was done in base 2, then base 3, then base 5, then base 3, and then base 2 again, the number would look wildly different (even a different number of digits).
The problem with this encryption operation is the overhead. Converting a number to a variety of different bases is extremely costly. I'm looking for another encryption algorithm that can take a key and a number and encrypt that number using that key without storing any extra data. The encryption algorithm should start becoming effective with at least 8 bits of data and should be much lower overhead than my current algorithm here =).
Beyond the encryption I am using a knuth checksum and a crc. Yes, I could do the crc solo, but the number can be of different versions, so I am actually storing the version into the checksum and using the crc to do final version verification.
checksum = checksum + version
crc = version
What this means is that the crc is there to do out of bounds checking and ensure that the checksum retains its effectiveness.
I am not encrypting text. I am encrypting positive base 10 integers that may be between 3 and 140 digits long. I am already using cipher substitution with a generated alphabet on top of this.
If anyone could help me out with this, that'd be much appreciated ^)^.
Now, this algorithm appears to work quite well, but it has a massive amount of overhead. When I run it in the environment that it's coded for, the entire application freezes for 1.5ish seconds for a 60 digit base 68 number (yes, the language for this environment is ridiculously slow as well).
My current encryption algorithm takes a set of prime bases to encrypt the number for as well as an amount of shuffles to do in each base. From here, it also uses a unique identifier of the user (like an account name) put together with a private key to generate the scrambling key.
For the cipher, it uses the user's unique id and a second private key to scramble the original cipher into a new cipher using the user id + private key to generate the scrambler key. The scrambling is done in the original cipher's base, so it's like a permutation.
On top of all of this, it also modifies the checksum based on a unique id and a third password as well as a variance value (variance being checksum variance). A value of .85 would give 15% variance. If max checksum was 1,000,000 (excluding 0 since it's easier to visualize then), the range would be 850,000 - 1,000,000.
Anyways, the weak point in all of this (the thing that actually freezes) is the scrambler resource: the thing that does the swapping.
Thank you for taking the time to read this long post =).
Also, given that I'm using a hardly used language, I would have to code any suggested algorithm from scratch, so when suggesting an algorithm, please provide some sort of link that goes over how to do it and why it works. Thanks =).