[Back]

The translations have been made by the excellent DeepL translation service. Please look past imperfections in words and phrasings.

[2026-08-01] lo_encrypt.py: Encryption method with partial string rotation using part of the salt and inbedded timestamp for validation

For encryption of API keys/text messages between client/client, server/server, server/client or server/client and back. The original key is encrypted and then partially rotated at a known range using part of the salt. Easy example "0000000000aaabbbcc" + "4bdd7" at time revolved pos[2:6] -> "004bdd7000aaabbbcc" A timestamp is generated and encrypted to obfuscate it from looking like a timestamp, thereafter inserted after the partially rotated section. "004bdd700aaabbbcc" ^ insert encrypted timestamp (using salt) QxPeztKSpkMPyQ for 1785535200 (equals 2026-08-01 00:00) The section to rotate is defined by a schema, the same on the sending and the receiving part: HH:MM: [pos1, pos2]: {"00:00": [1, 21], "00:10": [2, 41], "00:20": [21, 39], "00:30": [15, 35], ...} Upon decryption, a one step look-back can be used if failing, i.e. accepting keys from some time back, to allow for overlap as the time schedule is kept both on the sending and receiving part. The schema can be updated daily by sending it from the sender to the receiver using this encryption. Even if the salt is guessed ("password is decrypted"), the key is protected by the inserted encrypted timestamp and the encrypted and partially rotated original key. Not knowing how to decrypt the key fully will result in usage of unauthorized keys if compromised, which can then be detected. Usage of old keys will also be detected at time of decryption. Base64 encoded SHA-256 for internet use. Raises DecryptionError upon failed decrypt. lo_encrypt.py [GitLab] The idea started simple this morning, when appending a timestamp to a secret key before encrypting it to enable time validation when receiving it back again. Then realising someone breaking the key could likely read out the timestamp no matter where it was placed in the decrypted secret since it was all digits (e.g. 1785535200), and adjust it before recrypting it. Also, a few characters in my secret key was also in plain text. Then on to rotate a part of the original key to make it reversibly invalid (using the same salt), so I could detect unauthorized usage if someone sent the invalid key together with an adjusted timestamp. The final idea became to encrypt a readable text, rotate a section of it using part of the same salt, and insert an encrypted timestamp directly after the rotated part (to make that indistinguishable from the encrypted text and seemingly arbitrary positioned), and then encrypt the whole deal. This is reversible as the salt and the rotation schedule is known both by the sender and the receiver. [Visible Planets] and key exchange with the payment system Stripe: The server adds a lo_encrypted key together with the planet calculations to the client, clicking the Donate button results in a return of the same encrypted key back to the server, which then validates the inbedded timestamp and then the key itself, before making a request to the payment system and sends that unique key back to the client. No attackable API keys out to the client and time validation of the "multi level" encrypted key sent. My server payment key API is protected by cache at Cloudflare.