Nestharus
o-o
- Reaction score
- 84
So I've been trying to update an encryption algorithm I'm currently using (example of output http://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.
[1]9455
[1][5]35395398
5135395398
1[9]455
[5][1]35395398
1535395398
19[4]55
15[3]539[5]398
1555393398
194[5]5
155[5]3933[9]8
1559393358
1945[5]
1559[3]9335[8]
1559893353
[1]9455
15598[9][3]353
1559839353
1[9]455
155983[9][3]53
1559833953
19[4]55
15[5]98339[5]3
1559833953
194[5]5
1559[8]3395[3]
1559333958
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 to ensure that the checksum retains its effectiveness
Oh yes, and I know that by making the encrypted number around the same size as the original number that the encryption actually becomes much weaker, but that's how it needs to be. The size of the encrypted data is very important. I want it to be as small as possible. An encryption algorithm that adds absolutely nothing like the one I have right now is ideal. The problem with this current one is that it freezes for a second whenever I use it =p.
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 ^)^.
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.
[1]9455
[1][5]35395398
5135395398
1[9]455
[5][1]35395398
1535395398
19[4]55
15[3]539[5]398
1555393398
194[5]5
155[5]3933[9]8
1559393358
1945[5]
1559[3]9335[8]
1559893353
[1]9455
15598[9][3]353
1559839353
1[9]455
155983[9][3]53
1559833953
19[4]55
15[5]98339[5]3
1559833953
194[5]5
1559[8]3395[3]
1559333958
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 to ensure that the checksum retains its effectiveness
Oh yes, and I know that by making the encrypted number around the same size as the original number that the encryption actually becomes much weaker, but that's how it needs to be. The size of the encrypted data is very important. I want it to be as small as possible. An encryption algorithm that adds absolutely nothing like the one I have right now is ideal. The problem with this current one is that it freezes for a second whenever I use it =p.
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 ^)^.
