will likely cause encrypted secrets to decrypt incorrectly. It’s advisable to only use this tool ahead of launch.
Why is that?
There are no rows in this table
🏃♂️ Performance Notes
If you notice things have slowed down a bit, this may be helpful advice.
Of course, as more rows are added to the Char Mapping table, the time to Encrypt/Decrypt will increase. I haven’t benchmarked this. You could look at this as a positive thing (the basis of good encryption is that the operation to encrypt/decrypt takes enough time to dissuade brute force attacks), however this could have a negative impact on the user experience of the system.
At the end of the day, I’ll leave that decision up to you :)
Default Character Sets:
The three Unicode Latin Basic character sets:
Punctuation & Symbols
Uppercase & Lowercase
The “new line” character (equivalent of pressing Enteron your keyboard.
A couple strange characters here and there which caused issues in testing - things like “curly quotes” when copying out of Microsoft Office products, and “em/en dashes”.
Finally, I included a set of Uppercase & Lowercase characters from Latin-1 Supplement. (see notes alongside 👉)
I primarily included the Latin-1 Supplement block to help prevent corruption that could happen when users add or remove individual characters or entire character sets to the Character Mapping after items have already been encoded.
During encryption, some characters end up “out of range” because the sum of their index and the corresponding character in the key’s index exceeds the available characters in the table. To map them to a character (in order to generate the ciphertext), we loop back to the beginning of the table. When the Count() of the available characters changes, these out of range characters end up decrypting to the wrong characters and we get corrupted text. This Latin-1 Supplement block therefore serves as a kind of “buffer” to help reduce the likelihood of this happening often when changes are made to the character mapping table.