Tutorial: Masking Messages With plain_sight in Your Browser

Suppose you would like to exchange a set of messages with another person, but you would like to prevent any third party from realizing that a message has been transmitted.

Now suppose that you and the other person are frequently exchanging some type of regularly formatted data, or could reasonably start to exchange data like that. This would be an ideal situation for the use of plain_sight. You would create a custom rule file that produces files that look like the commonly exchanged data but actually contain encrypted messages. For the purposes of this tutorial, let’s presume that the two parties frequently exchange server login logs.

To begin, both parties should meet and get on the same page. Both parties must have the following:

  • Some kind of plain_sight terminal.
  • The same rule file.
  • The same encryption key or password.

The easiest to use plain_sight terminal is an html file available for download here: plainSight.html

The rule file which we will use in this tutorial is available here: loginLog

The password can be any combination of printable ASCII characters of any length. A single letter can be used or the full text of War and Peace. I recommend using either 10+ characters of mixed special characters, capital letters, numbers, and lowercase letters or a set of 5+ dictionary words and/or proper names strung together or in sentence form. So good passwords would be either something like “s4^hw!Q#334|{}jdE4$” or “Jon says this password is easier to remember.” For the purposes of this tutorial we will use the password, “The jabberwocky invented the slushy hail mary.”

Now suppose that you want to send the following message:

Sound Check. Testing. Testing. 1,2,3. Sippowitz. Syllabus. Clown. Callow.
Callous. Google. Go Ogle. Google.

The first step would be to open plainsight.html in your favorite browser. It should look like this.


Here you can see that there are directions right at the top of the page for reference. In accordance with step 1, the message you want to mask should be pasted into the “Text to Process” box as so:


Next you need to open the previously downloaded rule file “loginLog.” Just click on the “Browse” button located immediately below the “Rule File:” label. Then navigate to where the file is on your computer, highlight it, and select “open.”


After hitting “open” the browser should look like this:


Next, you want to make sure to encrypt the file, so check the “Encrypt?” check box which will enable the password box. Select the password box and type in “The jabberwocky invented the slushy hail mary.”


Finally, hit the “HIDE” button and the output box will be automatically filled in with the masked and encrypted message.


Now you can select the masked message and copy and paste it into a file, email, paste bin, forum, or chat for transmission to the other party.

Once the other party has the concealed message, they just need to open up plainSight.html in their browser and repeat the same steps except that the masked message goes into the “Text to Process” box, and the “UNHIDE” button should be hit after opening the rule file and entering the password. When they do, the original message will appear in the output box.


And then the message will have been received.


I put together a little utility to allow easy access to cipherClock encryption and uploaded it to github. This implementation uses a key length of 128 (which corresponds to 256^128 possible keys) and uses 128 gears. Thus, for most classical form passwords, the encryption will be as difficult to crack as the password. However, since the program allows passwords of arbitrary length, one could use a password string long enough that the password becomes more difficult to crack then the key. This would require a very long password, and even if this is done, an attacker still has to find a needle in a needlestack containing 256^128 needles.

Available here:


CipherClock in hardware

It occured to me that the stream cipher nature of CipherClock, makes it quite easy to incorporate directly into an 18 pin integrated circuit for real time encryption/decryption of 8-bit data. The key would just have to be loaded by a serial interface or built in during fabrication (with each key getting a series of chips built for it), or loaded and then made permanent during quality testing of the completed chip before shipping to customers.

Or indeed, for hardware security within a computer system, a CipherClock module can be built into the processor and every other device on the bus (with 1 CipherClock module per 8 bits of bus.) to make all inter-device communications secure.

The main issue with these ideas is that CipherClock isn’t currently designed to operate on all 256 possible 8 bit inputs, but I could easily modify it to do so.

The plain_sight encryption system: CipherClock

I went to the trouble of making an effective cryptographic system for plain_sight, so I’ll give it a name, CipherClock and some explanation.

CipherClock is a single replacement algorithm which operates on all printable ASCII characters plus “space” and “new line.” It replaces each character of the plain text with a single cipher character in the same position. The cipher character is calculated from the key and from the position of the character in the message (referred to as the index).

The calculation of the cipher character cannot be reversed without having the key (except in certain weak key cases), or without knowing the index of the character in the message. Because there is no transposition or other moving around of the characters, this algorithm is a Stream type algorithm suitable for use in real time encryption of outgoing signals and decryption of incoming signals.

CipherClock uses a key consisting of an array of 20 integers which can have any value between and including 31 and 125 (31 is used to store the new line character which normally has the ascii character code 10). There are 95 possible values for each integer, and therefore there are 95^20 possible keys which is the equivalent of between a 131 bit key and a 132 bit key. This massive number of possibilities makes it unreasonable to attempt to brute force decrypt (guess and check every key by using all available computing resources) any encrypted message.

CipherClock calculates the cipher character by adding a combination of the key integers to a set of three rotating values. The exact combination of the key integers to use is selected from a rotating set of 27 different combinations, and the rotating values rotate by a set length with each incremental index position. The rotation lengths of the rotating values are pre-calculated based on properties of the key. The sum of all of these gears is then the number of positions (on the set of ASCII characters) by which to rotate the plain text character.

The main security of CipherClock is insured by the rotating set of 27 different key component combinations. The other three rotating values insure that even if the plain text is somewhat repetitive every 3, 9, or 27 times, the cipher text will not reveal nor highlight whatever useful information might be hidden in the small variances of that repetitive input.

Keys are weak if all integer values within the key are the same, but this can be easily detected and guarded against.

A cryptography observation: the odd wheel.

It is well known that the function 1/x generates a huge set of different numbers for x between 0 and 1. For this reason, this function can be used to transfrom a single piece of data into a wide range of possible alternatives. But you have to have a method to extract those alternatives and bind them to the range you require. I do this through the creation of an odd wheel, which is a range of numbers with an odd length. With this range defined, I then take the wider ranged number and subtract the odd wheel from it until my result lies within the range. Then I will have a result which is bound to my desired range, and that varies wildly with small changes in x.

Think of it like the more standard 360 degree circle. If I have an angle greater than 360 degrees, then my actual location on the circle is determined by subtracting 360 from my oversized angle until I get a result between 0 and 360. But, for say cryptographic applications an even numbered range has the potential of leaving one vulnerable to having a propensity for an even or odd result. If my x or my function for calculating the large widely range number has any tendency towards being even or odd, then an Even wheel will pass that tendency directly to my result, leaving me with a less secure range. However an odd wheel will switch whether the result is even or odd each time it iterates through the subtraction, leaving one with a better range as long as the magnitude of the wide ranging input is sufficiently varied.


It occurs to me that my text masking program (see the menu entry above) can be used to disguise text files as valid html pages. Since the text input can also be itself an html page, it becomes possible to publish an html page on the internet that looks like one thing, but is actually a secret page, whose html can only accessed by unhiding with the correct plain_sight rule file. This, of course, creates the possibility of a new layer of deep web, a potential masquarade ball of hidden information. Not that I’ve done that here, or that I’ve any need to do that, but it is a stimulating premise.