Difference between revisions of "Talk:Basic Encryption Modules"
Line 1: | Line 1: | ||
I am suspect of the math involved in this function and would at some point like to fix it. In the current state it is possible for the randomizer to cause the output to change between runs on the same input. This could be solved by reverse sorting the letters in the decrypter or by properly setting the characters on powers of two in the hash table. [[User:Strife Onizuka|Strife Onizuka]] 18:31, 5 March 2007 (PST) | I am suspect of the math involved in this function and would at some point like to fix it. In the current state it is possible for the randomizer to cause the output to change between runs on the same input. This could be solved by reverse sorting the letters in the decrypter or by properly setting the characters on powers of two in the hash table. [[User:Strife Onizuka|Strife Onizuka]] 18:31, 5 March 2007 (PST) | ||
Thanks, it was not really made for anything practicle, it was just something that someone had asked to see if/how it could be done. It was mostly just intended to be a demo, and sufficiently hard enough to crack that it would be unlikely for anyone intercepting the message to understand it. Not to mention, it's pretty rare to need to send floats. I would think that for most communications, simply swapping letters in a string and changing channels would be sufficient. For those that need more, using multiple strings with different character runs and adding a 3rd field to indicate the run to use for the next decryption would probably work too. Perhaps one of these days, if i were to actually need it for something, i might work on it again. As far as the randomizer causing errors, i have not seen any, all the differences that I have seen come from how the float is rounded. If you llOwnerSay the float before encryption, and after decryption it is always the same. BUT it is sometimes rounded differently. there are other scripts available though forbreaking up floats to retain their correct value which could be used in conjunction to retain the correct value for the float. |
Revision as of 17:27, 10 March 2007
I am suspect of the math involved in this function and would at some point like to fix it. In the current state it is possible for the randomizer to cause the output to change between runs on the same input. This could be solved by reverse sorting the letters in the decrypter or by properly setting the characters on powers of two in the hash table. Strife Onizuka 18:31, 5 March 2007 (PST)
Thanks, it was not really made for anything practicle, it was just something that someone had asked to see if/how it could be done. It was mostly just intended to be a demo, and sufficiently hard enough to crack that it would be unlikely for anyone intercepting the message to understand it. Not to mention, it's pretty rare to need to send floats. I would think that for most communications, simply swapping letters in a string and changing channels would be sufficient. For those that need more, using multiple strings with different character runs and adding a 3rd field to indicate the run to use for the next decryption would probably work too. Perhaps one of these days, if i were to actually need it for something, i might work on it again. As far as the randomizer causing errors, i have not seen any, all the differences that I have seen come from how the float is rounded. If you llOwnerSay the float before encryption, and after decryption it is always the same. BUT it is sometimes rounded differently. there are other scripts available though forbreaking up floats to retain their correct value which could be used in conjunction to retain the correct value for the float.