>>>>When testing the use of the table PK as a seed, padded with '0's the encrypted string is different but very similar. Because most of the characters in seed are the same. For example, for PK 5 and PK 6. It would still make it very difficult to crack.
>>>>I added another "twist" to this approach.
>>>>Instead of using the PK as a seed, I use the PK*369 (or any other number that I won't share with anybody :)).
>>>>The resulting number/seed then has more different characters than simply PK.
>>>>Example:
>>>>5*369=1845 - Seed "1845"
>>>>6*369=2214 - Seed "2214"
>>>>This way the Seed is even more difficult to guess, even if someone has the cipher() code.
>>>
>>>Your solution was exactly what I was going to recommend after reading the first sentence. You nailed it. :-)
>>>
>>>Another way to do this is to use something other than a random string. The data source to obscure the text only has to come from some source. You can use an image and read the RGB() colors from the image in a defined rectangle that your algorithm determines based on some combination of PK values. You then read each pixel, process the characters in sequence using the R channel (0..255), G channel, B channel, and then repeat. If you use a sufficiently noisy image, it would be very hard to decipher. You can also use a stride, so that you don't increase by 1 pixel each time, but move about the image from some starting point in a random jumping pattern.
>>>
>>>Any kind of algorithm to read in seemingly random data, and then to augment the characters in that way, replacing the getRand() function with whatever algorithm you want to read in "random" things.
>>
>>Rick,
>>Thank you for another suggestion/input.
>
>Something else you can do if it appears to be too repetitive is to encode a stride (using every Nth random number), or to use a summation algorithm so you don't just use the getRand() values, but rather multiply them by the iteration count, or add in a sum of the integers from the datetime() the record was created (add in 12 + 31 + 2019 + 08 + 17 + 52 if it was 12/31/2019 08:17:52, for example), or whatever else you want to do.
>
>The sky's the limit. Make it unique, put your stamp on it, but make sure you document it. There's no going back without the reversal key.
>
>You can also use GNU's Privacy Guard encryption technique and store the information in a large public key / private key block cipher. These are the algorithms which drive the Internet and its security, using very large prime numbers multiplied together, making it very difficult to break. With GnuPG, you can create arbitrarily long / secure keys that would require a tremendous amount of time to decrypt.
>
>https://www.gnupg.org
>
>Lots of methods. The one I gave you was just one to obscure it. It would be hackable if someone was so inclined.
>
>If you want a more complex random number generator, you can use other algorithms which are public, and intermix them with ratios following sin() waves or whatever, so that you blend in from multiple sources. It would make it very difficult to figure out without knowing the sequence you used.

Wow. A lot of choices and possibilities. The only thing you lost me is when you said "make sure you document it". What is "documentation"? :)