h a l f b a k e r ynon-lame halfbakery tagline
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Rot19
up to four times more secure than Rot13! | |
It's fairly common practice to obfuscate spoilers and other random trivia using Rot13. This is a basic substitution cipher where each letter is replaced by that 13 along the alphabet - with wrapping at the ends.
This 'encryption' is good enough for some purposes, such as preventing accidental reading
of undesired information. It has the advantage that the encryption algorithm is identical to the decryption (since 13 is half of the modern 26-letter alphabet length). However, the system does have a few annoying flaws. Numbers and punctuation are unmodified, and hence may leak information to the discerning viewer.
Also multiple items may be accidentally rotted, such as when reading the first of a series of clues.
I propose a derivative to address these failings. Rot19 incorporates a larger range of the common ASCII characters - from ASCII 32 (space) to ASCII 126 ('~'). This is 95 symbols. 95 has the prime factors 5 and 19, which suggests that one could encode text by rotating it a multiple of 19 places, and decode by repeating the process until the text becomes legible again.
For example A >> T >> g >> z >> . >> A
Where weak protection is required one could encrypt 4 times (allowing a single decryption step); where stronger protection is required one would encrypt fewer times. This yields obvious advantages where a series is desired[1]. Furthermore, as essentially all characters are encoded[2], less information 'leaks' to the casual gaze.
[1] If a series longer than 4 (or even more security) is required, combine with Rot13.
[2] Control codes - and in particular newlines - are not. Including newlines would be problematical due to variation between systems.
Unix: tr
http://www.linfo.org/tr.html
Translate command - swaps letters for other letters [zen_tom, Apr 09 2009]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I've always thought of the other version as applying only to a wrapping-round code of letters whose case is irrelevant rather than ASCII. I can see the point of using nineteen instead of thirteen, but a space will still be a '3' and after a while you'd get used to it and see it as English. If a single letter is flanked by '3''s, that letter will probably be "a" or "I", and once you've recognised such a letter on its own, you'll recognise it elsewhere and it would start to give things away. What do you think about XORing with the code of an initial randomly chosen printable character? That would allow a single operation to convert to the coded form and back in the same way as it now does, but with less risk of getting used to the encoded forms.
That doesn't mean i dislike your idea and i'll vote for it. |
|
| |
But the advantage of rot13 is that it can be decrypted by a person easily. It offers almost zero actual security, if you want that you'd encrypt it properly. |
|
| |
Using all the symbols in that range would be too hard to decode by thinking about it. If you wanted numbers included, maybe just a to z and 0 to 9 would be best, with a rot18 function to encrypt and decrypt. |
|
| |
I would expect that which was fairly easy to decrypt would eventually become second nature and be hard to avoid reading. Having a random character to swap some of the bits would mean there were around a hundred options for confusion, but which could be reversed in a single step. |
|
| |
Why does the number have to be a prime factor ? |
|
| |
I've got a two-liner somewhere that performs a rot47 (47 is half of 94 so I'm guessing that's uppercase, lowercase, numerics and various punctuation marks that you mention - perhaps I chose to maintain spaces as-is) on some text - I can't remember the details, but essentially, you define your allowable character set, count how many elements are in it, then divide that number by two (you do need to have an even number of characters) and that's your "rot" number. |
|
| |
e.g.
tr ABCDEFGHIJKLMNOPQRSTUVWXYZ NOPQRSTUVWXYZABCDEFGHIJKLM
will do a rot13 in UNIX on all uppercase characters
while
tr ABCD CDAB
will do a "rot2" for the limited set of characters ABCD. |
|
| |
So, just pad out your dictionary strings to be as long (n) as you like with whatever characters take your fancy, and boom, you've got rot n/2. |
|
| |
That allows for the nice and easy toggle nature of rot13 (i.e. perform the technique to either encrypt, or decrypt, rather than shifting through various versions of encryption before finding the one that works) If you want it to be 'really' secure, just do a rot1 and it will take up to 25 subsequent 'rotations'(assuming say, only uppercase characters are used) for the message to reveal itself. |
|
| |
I've always thought there is a lot of mileage in "just good enough encryption". Most applications regular people have for encryption don't need to use unbreakable codes. |
|
| |