For reproducability by an independent third party, all validation was performed using desktop office software to generate random numbers from known 'Random Seed' values (see Table II, below) using a "Uniform" distribution.

The initial approach involved the generation of numbers representing a possible combination of parameters from a population of all possible combinations of parameters.

• A two-digit binary number was assigned to select parameter 'type'.
• A three-digit binary number was assigned to select parameter 'base', in a manner similar to that used to select the special character set in the revised protocol.
• A three-digit binary number was assigned to select one of the special character sets in Table V, below, for inclusion in the plain text alphabet.
• Five-digit binary numbers were assigned to determine whether parameters 'keyword', 'key', and 'plaintext' contained valid or not valid characters, or both; escaped or not escaped characters, or both; or duplicates.

Each test case was therefore represented by a single 23-digit binary number. The total number of possible combinations was 8,388,608. A later revision reduced the total number of possible combinations to 1,048,576 by reducing the number of digits assigned to parameters 'keyword', 'key', and 'plaintext' from five to four. A real number between 1 and the total number of possible combinations was generated. The number was rounded to the nearest integer value. This number was translated into binary. The digits of the number were then read from left to right, and used to generate the parameters for each test case: the first two digits represented parameter 'type', the second two represented parameter 'base', and so on.

This approach was rejected because the inclusion of some variable number of special characters and some variable number of duplicates did not reliably result in valid parameters. Many test cases failed to produce meaningful ciphertext. It was determined the population of all possible combinations of parameters includes many invalid combinations. For example, this approach resulted in five of every eight test cases automatically being invalid because only '100', '010', and '001' were valid values for parameter 'base'.

To resolve the problem, parameters were adjusted as necessary to produce meaningful ciphertext. However, no standard method reliably resulted in valid parameters. For example, converting letters to numbers in accordance with a known scheme (1337) sometimes resulted in valid parameters, but not in every test case, and converting some lower case characters into uppercase characters sometimes resulted in valid parameters, but not in every test case.

An approach which required the manipulation of randomly generated parameters was determined to be too subjective, and the generation of, and subsequent rejection of, large numbers of invalid combinations in search of those combinations which are valid was determined to be too time consuming. An approach which reduced the number of invalid combinations, while still providing reproducibility and reasonable assurance the utility functions as intended, was adopted.

1. Parameter selection.
   1. For parameters 'type', 'base', and 'set' one real number was randomly generated for each test case, as one of a series of twelve numbers, using the 'Random Seed' in Table II, below.
      1. For parameter 'type', a real number between 0 and 3 was randomly generated. The number was rounded to the nearest integer value. The integer value was converted to binary and used to determine the value of parameter 'type' in accordance with Table III, below.
      2. For parameter 'base', a real number between 1 and 3 was randomly generated. The number was rounded to the nearest integer value. The integer value was converted to binary and used to determine the value of parameter 'base' in accordance with Table IV, below.
      3. For parameter 'set', a real number between 0 and 7 was randomly generated. The number was rounded to the nearest integer value. The integer value was converted to binary and used to determine how many special characters to include in the plaintext alphabet, and from which special character set(s). A '1' in the first place ('1XX') corresponds to the first set, a '1' in the second place ('X1X') corresponds to the second set, and a '1' in the third place ('XX1') corresponds to the third set. Four characters from each selected set were randomly generated. See parameter 'special'.
   2. For parameter 'special', four real numbers between numbers representing the first and last characters in each selected set were randomly generated, from known 'Random Seed' values (see Table II, below). Each number was rounded to the nearest integer value. The integer values were converted to characters in accordance with Table V, below.
   3. For parameters 'keyword', 'key', and 'plaintext', twelve real numbers between 1 and 95 were randomly generated for each test case, from known 'Random Seed' values (see Table I, below). Each number was rounded to the nearest integer value. The integer values were converted to characters in accordance with Table VI, below.
2. The validation protocol.

   For each combination of parameters selected:

   1. Verify the parameter 'type' selector selects the correct cipher method, and is reported correctly.
   2. Verify the parameter 'base' selector selects the correct base alphabet, and is reported correctly.
   3. Verify the parameter 'special' and unique selected special characters are reported correctly.
   4. Verify the intermediate variable 'plaintextAlphabet' is generated by inserting unique special characters, in ascending ASCII order, into the base plain text alphabet selected by parameter 'base', and is reported correctly.
   5. Verify the intermediate variable 'keyword' is generated by first extracting valid characters, then unique characters, from parameter 'keyword', in the order in which they occur in parameter 'keyword', and that parameter 'keyword' and intermediate variable 'keyword' are reported correctly.
   6. Verify the intermediate variable 'ciphertextAlphabet' is generated by appending all characters of the plain text alphabet not used by the unique key word to the unique key word in the order in which they occur in the plain text alphabet, and is reported correctly.
   7. Verify the intermediate variable 'key' is extracted from valid (but not necessarily unique) characters of parameter 'key', and that parameter 'key' and intermediate variable 'key' are reported correctly.
   8. Verify the intermediate variable 'plaintext' is generated by extracting valid (but not necessarily unique) characters from parameter 'plaintext', in the order in which they occur in parameter 'plaintext', and that parameter 'plaintext' and intermediate variable 'plaintext' are reported correctly.
   9. Verify the selected parameters and resulting intermediate variables produce correct ciphertext.

The selected parameters and resulting intermediate variables were validated in accordance with the validation protocol, above, and produced the ciphertext reported in Table I, below. The ciphertext may be reproduced from the selected parameters in Table II, below, using the utility or by hand, with one exception: the output of the 'Validate' button has since been revised to report both parameter 'special' and unique special characters, in lieu of only unique special characters reported initially. Columns 'Validate' and 'Tabula' link to the output of the 'Validate' and 'Tabula Recta' buttons for each test case.

Overall, the results support the assertion that the utility works as intended. However, the total number of possible combinations for just one twelve-character parameter is 95¹², which is a very large number, and it is therefore important to note that not all possible combinations can reasonably be tested.

Revisions affecting the results will be documented as necessary.