Memory:
In order to support several of its important security features, such as its ability to have all characters of the input affect all characters of the output, the OTG system must have some form of “memory”. In other words, its future must be affected by its past. In computer jargon we would say that it must be “stateful”, or able to “have state.”

State:
The OTG system has a finite number of states. In fact, it has exactly 676 (26x26) states, and it can be in exactly one of them at any time. In computer jargon the OTG system would be described as a finite state machine.

Location:
How do we create a simple system having “memory” and “state”? We do it by using a grid on a piece of paper, where at any point in time we are located at one specific position on the grid.

But let's back up for a moment since we're getting ahead of ourselves. Consider this (simplified for clarity) grid containing a very special arrangement of lowercase alphabetic characters:

Even after studying it for some time it probably looks rather random. It actually IS very random (which is a good thing for our purposes). But it was also deliberately and carefully designed by some clever software to have exactly ONE very important property. Can you see what it is? If you have a theory, or if you give up, click the button below to add some highlighting to just the 'a' characters and study their relationship.

Do you see what's so special?
What's very special about the grid of characters above, is that EVERY character, not just the 'a's, appears exactly ONCE in every row and column of the grid. This special grid organization is called a Latin Square (see wikipedia if you're curious to know more) and it lies at the heart of the operation of the OTG system. In computer jargon we would say that the OTG system is a finite state machine defined by a Latin Square.

GRC's Latin Squares Workbench

During the early development of the OTG cipher system, we needed to develop, prove, and demonstrate a number of theories of Latin Square manipulation (in order to make them for ourselves). To aid in this research we created an interactive “Latin Squares Workbench” to allow for the comfortable manipulation and experimentation with Latin Squares from 3x3 to 6x6. You are invited to experiment with these intriguing mathematical constructions which have fascinated mathematicians for centuries.

Why do Latin Squares matter? . . .   Because they allow us to do this:

This was the key breakthrough I had when I was working to invent a means for creating “memory” and “state” for a domain name to password encryption system: If every row and column has exactly one of each character, then it is possible to move throughout the grid, alternating between movement along rows and columns. In each case, moving to the next character that occurs in the domain name. In this fashion our location depends upon the history of all previous characters, and where we end up is determined by every character.

The use of the Off The Grid cipher system proceeds in the following two separate phases:

The OTG system employs two “Phases” for the encryption of a domain name into a secure domain-specific password: The first phase determines the starting location for the second phase by tracing the first six of the domain name's characters through the Grid, as shown to the left and (larger) above. Once the first phase has determined the starting point, the second phase is used to emit the enciphered password characters. (We answer the question “Why only the first six characters of the domain name?” on the Tech Details and FAQ page.)

As shown in the diagram, each step alternates between following along a column or a row. Although you could start from any of the Grid's 26 columns, or any of the Grid's 26 rows, the most important consideration is consistency. So choose a method and stick to it, otherwise you will obtain different results from one use to the next. But, at the same time, this flexibility can come in very handy. If you should need to generate alternate passwords for the same domain (such as when a domain's password policies require that passwords are changed), a total of 26+26, or 52, different passwords are readily available simply by starting in a different row or column.

The general rule for standard OTG operation is to start along the top row, locating the first character of the domain's name there, then finding the domain's second character in the column below . . . and so on. You should study the larger diagram above for the six-character domain name “amazon” until this makes sense to you. (Remember, this is only a reduced-size demonstration OTG grid. The OTG introduction page contains a full randomly generated 26x26 Latin Square for reference if you want to practice tracing out other domain names.)

The second phase of the encryption process very similar to the first, but with a few additions:

“amazon” enciphers to “gcznegmacmzg”

As shown in the simplified diagram above, the second phase path BEGINS where the first phase path ends. In this way, the path traced during the first phase determines the starting point for the second phase. Therefore, the first six characters of the domain name participate in determining the starting point for the domain name's encoding during Phase 2. The row or column where the phase one path ends is the location where the first character of the domain name is found to begin the second phase's path.

During Phase 2, we use an “overshoot method” to select the two enciphered output characters for each single domain name input character. If you examine the diagram above you can probably figure this out for yourself.

Starting Phase 2 where Phase 1 left off, at the final “n” of “amazon”, we move horizontally (since just previously we had moved vertically to reach the “n”) to the first character of the domain name “a”. We then continue moving in the same direction, skipping over the character we're seeking, and outputting the next two characters we encounter, in order, along our direction of travel.

Thus, the first “a” of amazon encodes into “gc” since, after skipping past the “a” we first encounter a “g” followed by a “c”.

Next, having skipped two characters past the first “a” character of “amazon”, we are now located at the “c” character, the second character past the “a”. Since we always alternate between moving horizontally and vertically, and we just moved horizontally, we now move vertically. In the vertical row of our current location (containing the “c” where we are currently located) we move to the next character of the domain name, which is “m”. As before, we now overshoot the character we are moving to (the “m” of amazon at this point), continuing to travel in the same direction and outputting the two characters that follow it, in the sequence we encounter them. Therefore, the “m” of “amazon” encodes into the two characters “zn”, in that order. The encoding of the remaining four of the first six characters of the domain name continues in this fashion, alternating between moving along horizontal rows and vertical columns, finding each successive domain name character, skipping past it, and outputting the two characters that follow in the sequence they are encountered.

Before proceeding, please review the Phase 2 encoding diagram above
to make sure that the procedure described so far makes sense to you.

Since Phase 2 enciphering requires that we “overshoot” our target character, outputting the two characters that follow it, it is possible that there might not be any characters to follow if our target character is either on the edge or just one character away from it. When we encounter that situation we “wrap around” to the opposite edge of the grid, in the same row or column, to find the one or two characters past our target.

Imagine that instead of enciphering the domain name “amazon” we wish to encipher the domain name “amazom” (ending in the letter “m”). As we can see from our example grid, this is a bit tricky because after encoding the “o”, skipping past it and moving across the two following characters which we output (“cm”) we are left at the location of second character, which is an “m”. But now we need to encode an “m”. Since the grid we're using is a Latin Square, we know that the column we're in only contains one “m” character, and we're already standing on it, so we cannot move along the column to it. The solution is simple: We move one more character in the same direction we were moving to the next row or column (wrapping around if this would cause us to fall off the grid) and locate the character we wish to encode in that row or column. As we can see from the example to the left, the final “m” of “amazom” would encode into “ie”.

Mixed UPPER and lower case: For the sake of simplicity and clarity, the examples we have shown above have used only lowercase characters. The actual OTG system mixes upper with lower case characters to create much stronger (4096 times stronger) passwords than if its passwords were all either upper or lower case. The rule for using the OTG mixed-case grid (see the sample to the left) is to simply ignore the case of the grid's characters when looking up characters, and output the character's upper or lower case when recording the enciphered output. Note that the grid's horizontal lines and vertical coloration has no meaning of its own. Those are merely intended to serve as dividers to aid the user in keeping their place when scanning horizontally across the rows or vertically up and down the columns.

Numbers, hyphens (-) and dots (.): Internet domain names may contain numbers, hyphens, and separating dots. But if these additional twelve characters were included in the main body of the grid, giving them weight equal to the 26 alphabetic characters, the grid would be expanded from 26 by 26 to 38 by 38, and the grid's area would be increased from 676 cells to 1,444, more than doubling the grid's size. Mixing these twelve seldom appearing characters into every row and column of the 26 often appearing characters would increase the difficulty of finding the characters most often being searched for. These seldom used characters can be accommodated without increasing the grid's size by creating a simple “substitution table” located at the top center of every OTG grid. (See the sample above/left.) Any time a number, a dash, or a dot is encountered when examining the domain name's first six characters, that character is located in the center of the top border, in the grey region and the alphabetic character appearing immediately below it is used instead. Referring to the sample above, the digit '0' appearing in a domain name would be treated as if it were the letter “c” so a “c” would be searched for in the current row or column. Similarly, if a name-separating dot (.) character was encountered, it would be treated exactly as if it was a “u” while tracing the domain name's path.

What does it all mean?
You should now understand how the “Off The Grid” system operates. Using an OTG grid, the instructions above enable you to securely convert any string of characters, such as from an Internet domain name, into twice as many mixed-case alphabetic characters for use as that domain name's corresponding password. You need not write down the password if you choose, since you can easily recreate the same password from the same domain name at any time in the future.

Once you have used the Create/Print Your Own Grid page to create your own personal custom grid (which NO ONE ELSE will ever have) you will have everything you need to create secure domain-based website passwords using a simple "no tech" paper-based system that needs no batteries, can't be hacked, can be used forever, will never be incompatible with web browser upgrades, and on and on.

There are a number of pages shown in the link block below that you may wish to examine for additional background and information about this “Off The Grid” system: