I wrote Encryptor because I couldn't buy it.

1. Encryptor is designed to solve three common problems with passwords:
   1. Variability in the allowed character set.

      Encryptor records the plaintext alphabet characteristics established by the web service provider and which are therefore outside your control (see Encryptor - About - Password requirements established by the web service provider).

      The primary purpose for recording the plaintext alphabet characteristics established by the web service provider is to quickly and easily generate a conforming password using the combination of upper and lower case characters, decimal digits, and special characters allowed by the web service provider (or allowed character set, see Encryptor - Support - Glossary). Using the allowed character set ensures the potential search space is as large as possible. This is one of the advantages Encryptor provides you.

      Recording the plaintext alphabet characteristics established by the web service provider is also a convenience to the user when changing passwords or generating multiple conforming passwords for the same domain. For example, how many times have you attempted to log in to your bank, credit union, or other web service provider only to be confronted by a page informing you that "Your password has expired", requiring you to change your password to another conforming password before allowing you to continue?

      Encryptor makes it easy to generate another conforming password. You can either modify the original encryptor or create a new encryptor by copying and pasting an existing encryptor into the same document (recommended). By creating a new encryptor you preserve your previous password until you receive confirmation that your password change has been accepted. Then, based on your personal encryption algorithm, select parsable tokens which result in another conforming password. Retain the previous password or delete it, depending on your preference.

   2. Variability in complexity requirements.

      Encryptor records the complexity requirements established by the web service provider and which are therefore outside your control (see Encryptor - About - Password requirements established by the web service provider).

      The primary purpose for recording the complexity requirements established by the web service provider is to quickly and easily generate a conforming password which satisfies the complexity requirements established by the web service provider (see Encryptor - Support - Glossary). This is one of the advantages Encryptor provides you.

      Recording the complexity requirements established by the web service provider is also a convenience to the user when changing passwords or generating multiple conforming passwords for the same domain.

   3. Uniqueness.

      The purpose of Encryptor is to allow users to combine something they have, i.e., a document recording their choices, with something they know, i.e., their personal encryption algorithm, and create a unique password for each web service provider.

      Encryptor records the details of password generation which are outside your control as a convenience to you and uses parsable tokens which you specify to encipher plaintext. This is something you have.

      Encryptor supports the development and use of a personal encryption algorithm known only to you. Your personal encryption algorithm is the method by which the details of password generation which are outside your control and parsable tokens you specify are combined to generate a conforming password. This is something you know.

      Encryptor therefore makes it possible to use a unique password for each site you visit1.

2. The following design goals guided the development of Encryptor:
   1. The user will retain control of their data.

      By design, as the user you retain control of your data. Encryptor saves your data locally, and exports to standards-compliant XML for portability, backup, and retention. There is no "vault" providing a potential attacker with the opportunity to recover all of your passwords from a remote server the security of which is outside of your control. You do not need an account to use Encryptor. Continued access to your data does not require, nor will it ever require, recurring payment such as a subscription. There is not now, nor will there ever be, an annual fee.

      This is consistent with Allen's commitment to data portability (see Allen Analytical - About - Allen Analytical's commitment to data portability).

   2. Conforming passwords and other authentication tokens generated using Encryptor will be reproducible using pencil-and-paper methods.

      Encryptor records the plaintext alphabet characteristics established by the web service provider and which are therefore outside your control (see Encryptor - About - Password requirements established by the web service provider), allowing you to use pencil-and-paper methods with a much larger plaintext alphabet than those used with more conventional implementations of these methods. Although it is possible to re-create the tabula used with larger plaintext alphabets by hand, it is tedious and time-consuming, and for this reason was not readily adopted even when the pencil-and-paper methods were in widespread use. Encryptor allows you to use a larger plaintext alphabet than more conventional implementations easily and without re-creating the tabula by hand.

      The cipher types and corresponding encryption algorithms used by Encryptor are well-known and were selected to provide the user with the basis for an effective personal encryption algorithm. For example, the cipher types variously allow the user to: use a robust keyword to generate a ciphertext alphabet which varies depending on the allowed character set, use continuously running text as a key, or use plaintext as part of the key.

      The use of a personal encryption algorithm allows the user to select parsable tokens which are memorable. Encryptor stores the parsable tokens as a convenience to the user, but allows the user to mark some or all of them as private data, which is handled specially by Encryptor. As a result, Encryptor makes it possible to easily and quickly generate a conforming password or other authentication token without disclosing or recording the details required to re-create the password.

      As a result, ciphertext can be reproduced using pencil-and-paper methods.

   3. Conforming passwords or other authentication tokens generated using Encryptor will be indistinguishable from random text.

      Although the algorithms used to encipher plaintext are well-known, your selection of parsable tokens is unique. The combination of letters, digits, and special characters allowed by the web service provider may also be unique. As a result, for the plaintext lengths typically encountered when selecting passwords for web service providers (typically between 6 and 16 characters in length), the ciphertext is indistinguishable from random text.

   4. Users will be able to share an encryptor with others without disclosing their contact information to a third party.

      Select one or more encryptors, select "Export...", and archive the resulting XML file with a password, wrap it in an encrypted disk partition, or otherwise secure it. Send the resulting file to anyone you want by any means available. They'll be able to import the encryptor or encryptors you exported directly into their copy of Encryptor, provided you also share the access credentials to your file.

      This is consistent with Allen's commitment to client confidentiality (see Allen Analytical - About - Allen Analytical's commitment to client confidentiality).

   5. Encryptor will encourage multi-layered security, or "defense in depth".

      Encryptor records the details of password generation which are outside your control. For example, Encryptor supports the use of an arbitrary set of special characters defined by your web service provider. As a result, although this will not make an eight-character password a sixteen-character password, the potential search space is as large as the web service provider allows.

      You may further customize the search space, for example, by taking advantage of a potential attacker's assumptions about it. For example, you may deselect all options defining characteristics of the base alphabet such as "Upper case characters", "Lower case characters", and "Decimal digits", and enter a subset of any or all of these into the special character set box.

      In addition, by marking the keyword, key, or plaintext as private data, you gain an additional level of security when sharing an encryptor. The private data necessary to re-create the conforming password must be communicated via some other channel.

   6. Encryptor will solve one of the most common problems with passwords, memorability, by allowing the user to use memorable parsable tokens to generate conforming passwords or other authentication tokens.

      Encryptor uses parsable tokens which you specify to encipher plaintext. In addition, Encryptor supports the development and use of a personal encryption algorithm known only to you. Your personal encryption algorithm is the method by which the details of password generation which are outside your control and parsable tokens you specify are combined to generate a conforming password or other authentication token.

      As a result, the same memorable parsable tokens may be used to generate different conforming passwords for multiple web service providers without exposing the parsable tokens to discovery.

Endnotes:

References:

Some web service providers require conforming passwords to contain both upper and lower case characters, decimal digits, and special characters, or any combination thereof. Some web service providers may not reject a password which does not use both upper and lower case characters, decimal digits, and special characters, but it is in the best interests of the user to select a password which meets these requirements so that the potential search space is as large as the web service provider allows. In addition, the allowed special characters vary from web service provider to web service provider. As a result, some password requirements established by web service providers are outside your control.

Encryptor records the details of password generation which are outside your control. Users may change these at any time using the "Encryptor Preferences" button. This allows the user to record the unique requirements for each combination of name and domain. It is advisable to determine what the requirements are before generating a conforming password, because changing the requirements after generating a conforming password will change the password Encryptor generates.

The following options are supported:

1. Plaintext alphabet characteristics.

   See Encryptor - About - Plaintext alphabet characteristics.

2. Ciphertext complexity requirements.

   See Encryptor - About - Complexity requirements.

Keyword

The keyword.

Enter any arbitrary combination of characters. The unique, valid keyword is extracted from this value (see Encryptor - About - Intermediate variables).

The unique, valid keyword is used to generate the ciphertext alphabet. The ciphertext alphabet is used to generate the tabula for cipher types other than "Keyword substitution". If no keyword is provided, the ciphertext alphabet is based on the unmodified plaintext alphabet1.

Key

The key.

Enter any arbitrary combination of characters. The valid key is extracted from this value (see Encryptor - About - Intermediate variables).

Plaintext

The plaintext to encrypt.

Enter any arbitrary combination of characters. The valid plaintext is extracted from this value (see Encryptor - About - Intermediate variables).

Changes to a parsable token may not result in changes to the corresponding intermediate variable. For example, Encryptor generates the unique, valid keyword "albrecht" for all of the following keywords and conditions:

• "albbrecht", "albbbrecht", or "aallbbrreecchhtt"
• "albrechtALBRECHT" or "aAlLbBrReEcChHtT" (given a plaintext alphabet which does not include upper case characters)
• "_albrecht_" or "a;lbre&ch_t" (given a plaintext alphabet which does not include the special characters ";", "&", and "_")

Endnotes.

Ciphertext alphabet

The ciphertext alphabet.

The ciphertext alphabet is generated by appending all characters of the plaintext alphabet not used by the unique, valid keyword to the unique, valid keyword in the order in which they occur in the plaintext alphabet. This is algorithmically identical to generating the first row of the tabula.

Plaintext alphabet

The plaintext alphabet.

The plaintext alphabet is generated by combining characters from the character set(s) selected by the user: upper case letter, lower case letter, decimal digits, or unique special. The plaintext alphabet is sorted in ascending order. The sort order of the plaintext alphabet cannot be changed.

If only the 7-bit characters in the ISO-8859-1 character set (commonly referred to as "Latin-1") are selected, the plaintext alphabet is the ASCII character set[1], and is sorted in ascending ASCII order.

Encryptor's default plaintext alphabet contains 95 characters: the upper case letters A through Z, lower case letters a through z, decimal digits 0 through 9, and graphic characters of the 7-bit ISO-8859-1 character set (the ASCII character set), including space, which is a "...normally non-printing graphic character..."

Unique special character set

The unique special character set.

The unique special character set is generated by extracting unique special characters from the special character set entered by the user.

Unique, valid keyword

The unique, valid keyword.

The unique, valid keyword is generated by first extracting valid characters, then unique characters, from parsable token "keyword", in the order in which they occur in parsable token "keyword".

If the unique, valid keyword contains all characters of the plaintext alphabet, the ciphertext alphabet is identical to the unique, valid keyword.

Valid key

The valid key.

The valid key is generated by extracting valid (but not necessarily unique) characters from parsable token "key", in the order in which they occur in parsable token "key".

Although a key may be arbitrarily long, in practice it is not an advantage if the length of the valid key is significantly greater than the length of the valid plaintext.

The cipher type determines how Encryptor encrypts plaintext using the valid key (see Encryptor - Validation - Cipher type implementation for standard test cases used to validate Encryptor's implementation of cipher type):

1. None.

   A valid key is not required. Any value entered here is ignored.

2. Keyword substitution.

   A valid key is not required. Any value entered here is ignored.

3. Vigenère.

   A valid key is required.

   If the length of the valid key is zero, the user is informed that a valid key is required. No ciphertext is generated.

   If the length of the valid key is greater than zero, but less than the length of the valid plaintext, the valid key is appended to itself until the length of the valid key is greater than or equal to the length of the valid plaintext. The result is used to encrypt the valid plaintext using the tabula.

   If the length of the valid key is greater than or equal to the length of the valid plaintext, the valid key is used to encrypt the valid plaintext using the tabula. There is no difference between cipher type "Vigenère" and cipher type "Running key" if the length of the valid key is greater than the length of the valid plaintext. The user is informed that the cipher type is effectively "Running key".

4. Autokey.

   A valid key is optional.

   If the length of the valid key is zero, the valid plaintext is used to encrypt itself using the tabula.

   If the length of the valid key is less than the length of the valid plaintext, the valid plaintext is appended to the valid key. The result is used to encrypt the valid plaintext using the tabula.

   If the length of the valid key is greater than or equal to the length of the valid plaintext, the valid key is used to encrypt the valid plaintext using the tabula. There is no difference between cipher type "Autokey" and cipher type "Running key" if the length of the valid key is greater than the length of the valid plaintext. The user is informed that the cipher type is effectively "Running key".

5. Running key.

   A valid key is required.

   If the length of the valid key is less than the length of the valid plaintext, the user is informed that a valid key is required and that the length of the valid key must be greater than the length of the valid plaintext. No ciphertext is generated.

   If the length of the valid key is greater than or equal to the length of the valid plaintext, the valid key is used to encrypt the valid plaintext using the tabula.

Valid plaintext

The valid plaintext.

The valid plaintext is generated by extracting valid (but not necessarily unique) characters from parsable token "plaintext", in the order in which they occur in parsable token "plaintext".

References:

When requested by the user, Encryptor stores the authentication details associated with an encryptor in the user's default keychain as a keychain item using the Mac OS X v10.6 Keychain Services API ("Keychain Services API"). The default keychain is usually, but not necessarily, the login keychain. The user may use Keychain Access to designate a keychain other than the login keychain as the default, but Encryptor stores keychain items in the default keychain.

1. Creating a keychain item.

   The Keychain Services API supports the creation of keychain items for three types of password: "Internet password", "generic password", and "AppleShare password". Currently, Encryptor supports the creation of keychain items for type "Internet password". This is because Encryptor's primary core feature is the generation of a password which meets the minimum requirements established by a web service provider, i.e., a conforming password (see Encryptor - Support - Glossary). Encryptor does not yet support the creation of keychain items for passwords of type "generic password" or "AppleShare password", although this is a potential requested feature.

   When creating, modifying, finding, or deleting a keychain item for an Internet password, Encryptor determines the scheme (see optional parameter Protocol, below), server name, port, and path by parsing field "Domain" entered by the user as a URL. The URL providing these parameters must conform to RFC 2396. The Keychain Services API parses the URL in accordance with RFCs 1738[1] and 1808[2].

   1. Required parameters.

      To create a keychain item, three parameters are required:

      Account name
      

      The account name entered by the user in field "Name". Although the Keychain Services API provides a method for determining the user name of a URL conforming to RFC 1808, Encryptor uses the account name entered as field "Name" by the user as the account name when creating a keychain item.
      

      Server name
      

      The "host" of the URL. For Encryptor to determine the server name, the URL must conform to RFC 1808.
      

      Password
      

      The ciphertext generated by Encryptor. Although the Keychain Services API provides a method for determining the password of a URL conforming to RFC 1808, Encryptor uses the ciphertext generated by Encryptor as the password when creating a keychain item.
      

   2. Optional parameters.

      The following parameters are not required to create a keychain item, but may be required to use a keychain item:

      Path
      

      The "url-path" of the URL. For Encryptor to determine the path, the URL must conform to RFC 1808.
      

      Port
      

      The port number of the URL. For Encryptor to determine the port number, the URL must conform to RFC 1808.
      

      Protocol
      

      The protocol associated with the "scheme" of the URL.

      The Internet Assigned Numbers Authority (IANA) maintains a registry of permanent and provisional URI schemes[3].

      The Keychain Services API provides a method for determining the scheme of a URL conforming to RFC 1808. Because the Keychain Services API method used to find an Internet password returns the first Internet password based on the parameters passed, keychain items representing Internet passwords are not guaranteed to be unique, and it is advantageous to provide as much information as possible to ensure the first Internet password is the correct one before modifying or deleting a keychain item. It is therefore desirable to determine the scheme of a URL so that a user accessing an ftp:// resource or http:// resource requiring authentication can elect to use two separate Internet passwords for the same server name.

      To create separate Internet passwords for these resources, the Keychain Services API requires Encryptor to specify the protocol associated with each resource. However, there is no reliable correspondence between scheme and protocol. For example:

      • The user may enter a URL beginning with a scheme which is a permanent or provisional scheme recognized by IANA, such as "HTTP" or "http", and for which the intended protocol is clear.
      • The user may enter a URL beginning with a scheme which is neither a permanent nor provisional scheme recognized by IANA, but is nonetheless valid and in common use, and for which the Keychain Services API provides a corresponding protocol, such as "afp" or "ssh".
      • The user may enter a URL beginning with a scheme which is neither a permanent nor provisional scheme recognized by IANA, but is nonetheless valid and in common use, and for which the Keychain Services API provides no corresponding protocol, such as "sftp".

      The Keychain Services API defines 35 protocols, only ten (10) of which correspond to permanent schemes recognized by IANA. Encryptor supports the creation of Internet passwords for 24 protocols, ten (10) of which correspond to permanent schemes recognized by IANA and 14 of which do not:

      • The ten (10) protocols which correspond to permanent schemes recognized by IANA are (in alphabetical order):

        ftp
        

        File Transfer Protocol
        

        http
        

        Hypertext Transfer Protocol
        

        https
        

        Hypertext Transfer Protocol Secure
        

        imap
        

        Internet Message Access Protocol
        

        ipp
        

        Internet Printing Protocol
        

        ldap
        

        Lightweight Directory Access Protocol
        

        nntp
        

        Network News Transfer Protocol
        

        pop
        

        Post Office Protocol (v3)
        

        rtsp
        

        Real Time Streaming Protocol
        

        telnet
        

        TELNET
        

      • The 14 protocols which do not correspond to permanent schemes recognized by IANA are (in alphabetical order):

        afp
        

        Apple File Protocol
        

        cifs
        

        Common Internet File System
        

        ftps
        

        FTP over TLS/SSL
        

        imaps
        

        IMAP4 over TLS/SSL
        

        irc
        

        Internet Relay Chat
        

        ircs
        

        IRC over TLS/SSL
        

        ldaps
        

        LDAP over TLS/SSL
        

        nntps
        

        NNTP over TLS/SSL
        

        pops
        

        POP3 over TLS/SSL
        

        smb
        

        Server Message Block
        

        smtp
        

        Simple Mail Transfer Protocol
        

        ssh
        

        Secure Shell
        

        svn
        

        Subversion
        

        telnets
        

        Telnet over TLS/SSL
        

      • Encryptor does not support the creation of Internet passwords for the following protocols defined by the Keychain Services API (in alphabetical order):

        atlk
        

        AFP over AppleTalk (with the release of Mac OS X v10.6, the AppleTalk protocol is no longer supported)
        

        cvsp
        

        CVS pserver
        

        daap
        

        Digital Audio Access Protocol (proprietary)
        

        eppc
        

        Remote Apple Events (proprietary)
        

        ftpa
        

        Client-side FTP account (deprecated as of Mac OS X v10.3)
        

        ftpx
        

        FTP proxy
        

        htpx
        

        HTTP proxy
        

        htsx
        

        HTTPS proxy
        

        rtsx
        

        RTSP proxy
        

        sox
        

        SOCKet Secure
        

      This does not prevent a user from specifying a scheme which is not recognized as a valid protocol. When Encryptor is unable to determine the scheme of the URL, it creates a keychain item with no specific protocol. However, because the Keychain Services API method used to find an Internet password returns the first Internet password based on the parameters passed, keychain items representing Internet passwords are not guaranteed to be unique. As a result, Encryptor is unable to use the protocol to ensure the first Internet password is the correct one when modifying or deleting a keychain item.

      For example, Encryptor can be used to generate an Internet password for schemes "sftp" and "ftp" using the same account name and server name. The first will be stored with no specific protocol and the second as protocol "ftp". However, when multiple keychain items are created using the same account name and server name with schemes that have no corresponding protocol, there is a possibility that some collision will occur.

      This does not affect the creation of keychain items. However, when multiple keychain items are created using the same account name and server name with schemes that have no corresponding protocol, users may have to use Keychain Access to modify or delete a keychain item.

   3. Unused parameters.

      The following parameters are supported by the Keychain Services API, but are currently not used by Encryptor:

      Security domain
      

      The security domain of the keychain item.
      

2. Troubleshooting keychain items.

   Encryptor may not be able to create keychain items using information provided by the user. In general, Encryptor may not be able to create a keychain item for two reasons:

   1. Encryptor cannot create a keychain item for an encryptor.

      In general, this is because incorrect or inadequate information is provided by the user. Encryptor determines the scheme (see optional parameter Protocol, above), server name, port, and path by parsing field "Domain" entered by the user as a URL:

      • The URL providing these parameters must conform to RFC 2396. Ensure the URL conforms to RFC 2396.
      • The Keychain Services API parses a URL in accordance with RFCs 1738 and 1808. Ensure the URL conforms to RFCs 1738 and 1808.
   2. A keychain item is created, but it is incorrect.

      That is, the keychain entry created by Encryptor does not conform to the user's expectations.

      The question of non-conformity is tricky. The URL may begin with an unknown scheme or use non-standard port numbers which are perfectly valid. Encryptor attempts to use the information provided by the user to the extent possible, but problems may occur. If you encounter a specific problem which impacts your ability to use the keychain, please contact Allen.

References:

Encryptor prints the currently selected encryptor or first selected encryptor if more than one are selected ("selected encryptor"). If the cipher type of the selected encryptor is:

1. "None".

   The "Print..." command (⌘P) is disabled.

2. "Keyword substitution".

   Encryptor calculates the horizontal padding and offset necessary to center the plaintext and ciphertext alphabets ("alphabets") of the selected encryptor on one (1) page, and prints the alphabets.

3. Any other cipher type (currently "Vigenère", "Autokey", or "Running key").

   Encryptor calculates the number of vertically- or horizontally-tiled pages necessary to print the plaintext alphabet and tabula recta ("tabula") of the selected encryptor, calculates the vertical and horizontal padding and offset necessary to center the tabula (or portion of the tabula) on each page, centers the tabula on the tiled pages, and prints the tabula.

The number of vertically- and horizontally-tiled pages is calculated using a default line height of 1.5 and default point size of 10 points. Encryptor calculates the number of pages necessary to print the tabula using the printable area of the page. Changing the paper size or printing to a different printer affects these values. I am unable to test all possible configurations, so please send me an email if you encounter any problems when printing a tabula.

The tabula is, by necessity, square. However, the variant of the Vigenère, autokey, or running key cipher used by Encryptor does not necessarily use the plaintext alphabet as the first row of the tabula. If the user does not specify a keyword, the plaintext and ciphertext alphabets are the same and the first row of the tabula is identical to the plaintext alphabet. As a result, one additional row is required to print the plaintext alphabet.

It is possible to calculate the number of pages required to print the tabula. The following example is based on 38 columns per page by 48 rows calculated using the default line height of 1.5 and default font point size of 10 points, and the printable area of letter size paper when printing to a Samsung ML-1450, and shows the number of pages required to print the tabula for a plaintext or ciphertext alphabet having a length within the ranges indicated in the table. The number of rows is one less than might be expected based on the number of rows per page, because Encryptor prints the plaintext alphabet above the tabula. This reduces the number of rows available for printing the tabula on the first page to 47:

There are certain circumstances under which Encryptor cannot center the tabula. If the number of characters in either the vertical or horizontal dimension is even, Encryptor distributes the tabula evenly over the outer pages in that dimension when printing. If the number of characters in either dimension is odd, Encryptor cannot evenly distribute the tabula and prints an odd number of rows or columns on the top page(s) (for vertically tiled pages) or the left page(s) (for horizontally tiled pages), and an even number of rows or columns on the bottom or right page(s).

Because one additional row is required to print the plaintext alphabet, there will always be either an odd number of columns or rows, while the corresponding number of rows or columns will be even. As a result, the only circumstances under which print output is both vertically and horizontally symmetrical is when no tiling is necessary to print the tabula, or when the number of vertically- or horizontally-tiled pages in the long dimension (based on "Page Setup... > Orientation"), for example, the 11-inch side of letter size paper, is one, and the alphabets contain an even number of characters when the long dimension is vertical or an odd number when the long dimension is horizontal.

Future revisions will allow the user to print multiple encryptors at a time and implement a print dialogue featuring options allowing the user to:

• Print input to the encryptor.
• Optionally center the alphabets or tabula when printing. The current implementation of Encryptor's print behavior centers the alphabets or tabula when printing.
• Set the font to use when printing.
• Set the font size to use when printing.

Encryptor provides a way to mark parsable tokens as private data. Private data is handled specially by Encryptor:

• Encryptor prompts the user to clear private data before saving or quitting by deleting parsable tokens marked as private data, i.e., unlocked parsable tokens, but allows the user to Save or Quit without clearing private data (see Encryptor - Support - File save and quit behavior).
• Encryptor will not export parsable tokens marked as private data, providing additional security when sharing encryptors. The private data necessary to re-create the conforming password must be communicated via some other means.
• Encryptor will not copy parsable tokens marked as private data, providing additional security when copying and pasting encryptors into a text document.

The rationale for private data is multi-layered security, or defense in depth, one of Encryptor's design goals (see Encryptor - About - What makes Encryptor different from other password generators or managers?).

Encryptor remembers which parsable tokens are locked and unlocked for each encryptor. This is a convenience to allow the user to require Encryptor to prompt to delete a parsable token without which the conforming password or other authentication token cannot be re-created. After marking a parsable token as private data, Encryptor will prompt the user to clear private data before saving or quitting every time the user enters the parsable token for the encryptor.

There are three Remember... buttons, one for each parsable token (see Encryptor - About - Parsable tokens): Remember Keyword, Remember Key, and Remember Plaintext. The Remember... buttons lock or unlock the corresponding parsable token. By default, parsable tokens are locked, i.e., they are NOT marked as private data. The default may be changed for all encryptors (using application preferences) or for each encryptor individually (using encryptor preferences).

Clicking a Remember... button to reveal the "Locked" icon will lock the corresponding parsable token(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.

Clicking a Remember... button to reveal the "Unlocked" icon will unlock the corresponding parsable token(s) for the selected encryptor(s), marking the parsable token(s) as private data.

Changes to parsable tokens marked as private data will not be recorded as a change, and will not change the date the encryptor was last modified.

Most web service providers require or recommend the user select a password that is a mix of upper and lower case characters, decimal digits, and special characters, but do not disclose what special characters are allowed until after the user selects a password, confirms the password, and goes through a "password strength" check.

As a result, the user may select the strong, but memorable, password "sPo0kyh@l|0w3En" only to discover that the "@" or "|" (vertical pipe) symbols, both of which are used, are not allowed. The password is therefore not a conforming password.

After the web service provider reports this to the user, the user is forced to select another password and hope the special characters used are allowed. If the web service provider discloses the allowed special character set, it is more likely to do so after the user has selected a password containing special characters that are not allowed.

This is a worst practice, but it is very common. For example, at the time of account creation:

Google:

• does not disclose the special characters that are allowed. Google recommends: "Use at least 8 characters. Don’t use a password from another site, or something too obvious like your pet’s name." (see Create a new Google Account (Google)).
• does not disclose the special characters that are allowed, even on a page titled "Choosing a smart password", which recommends: "Use a password with a mix of letters, numbers, and symbols" (see Choosing a smart password (Google)).

Monster:

• does not disclose the special characters that are allowed. Monster requires: "8 - 20 characters (use at least 1 letter, and 1 number or symbol)" (see Become a Member (Monster)).

Facebook:

• does not disclose the special characters that are allowed, even in response to the questions: "What is the minimum password strength? How can I make my password strong?" Facebook recommends: "When creating a new password, be sure that it is at least 6 characters in length and that you use a complex string of numbers, letters, and punctuation marks." (see Creating an Account (Facebook)).

Because most web service providers do not disclose what special characters are allowed before the user selects a password, users of Encryptor may have to experiment to determine the allowed special character set when using Encryptor to generate a password.

Users of Encryptor may not be able to determine the allowed special character set unless they first generate a password containing a special character that is not allowed. Also, users of Encryptor may generate a password which does not contain a special character that is not allowed using a special character set which includes characters that are not allowed.

In the latter case, users of Encryptor should be aware that changing the special character set saved with the encryptor may change the ciphertext. If the ciphertext is being used as a password, users of Encryptor should be particularly careful when changing the special character set while using Encryptor to change the existing password. Encryptor fully supports "undo" operations, but undo history is not saved when the user quits. As a result, users of Encryptor should create a new encryptor using the revised special character set to avoid deleting ciphertext generated using the existing special character set, and which will be needed to change the existing password.

The features of Encryptor which are tested before any release is considered to be validated are:

1. The results reported by Encryptor to the user shall be correct.

   Encryptor's primary feature is performing operations on parsable string tokens to transform a plaintext string into a ciphertext string conforming to known requirements in accordance with a known encryption algorithm.

   All encryption algorithms used by Encryptor are pencil-and-paper methods which may be validated by hand. In general, they are suitable for encrypting small amounts of plaintext, such as a password, but should not be confused with modern cryptographic methods.

   Several encryption algorithms used by Encryptor were once considered indecipherable, and Encryptor will encrypt plaintext using a one-time pad as the key. However, the security of a one-time pad requires it never be used again, which defeats the purpose of storing it and would require that a password, for example, be changed every time it is used.

   Before every release, Allen evaluates Encryptor's ability to transform plaintext into ciphertext using standard test cases (see Encryptor - Validation - Standard test cases). The standard test cases have been manually validated, that is, validated by hand using pencil and paper.

   The reproducible bug bounty is: Manually encrypted ciphertext shall equal the ciphertext in field "Ciphertext" for every standard test case before the results reported by Encryptor to the user will be considered to be correct and the release considered validated.

   The standard test cases described are available as an XML document for download (see Encryptor - Downloads - Standard test cases). Import (⌘I) that document into Encryptor to validate Encryptor. The manually encrypted ciphertext is given in field "Comment".

2. Private data shall be cleared on "Save", "Save as...", or "Quit" when requested by the user.

   Before every release, Allen confirms that private data is cleared on "Save", "Save as...", or "Quit" when requested by the user. Encryptor's file save and quit behavior is described in the following document: Encryptor - Support - File save and quit behavior.

   The reproducible bug bounty is: Private data shall be cleared on "Save", "Save as...", or "Quit" when requested by the user in accordance with the behavior described in the document above.

3. Encryptor's user interface shall be resized appropriately when the user resizes the window.

   Before every release, Allen confirms that Encryptor's user interface is resized appropriately when the user resizes the window.

   The reproducible bug bounty is: Encryptor's user interface shall be resized appropriately when the user resizes the window.

4. Later versions of Encryptor shall import encryptors exported by previous versions of Encryptor.

   Before every release, Allen confirms that Encryptor imports encryptors exported by previous versions of Encryptor.

   The reproducible bug bounty is: Later versions of Encryptor shall import encryptors exported by previous versions of Encryptor.

   Note that Encryptor will both Export (⌘E) encryptors as an XML file ("exported XML file") and Save (⌘S) a document as an XML file ("saved XML file")1. Later versions of Encryptor will open a saved XML file, but saved XML files are incompatible with exported XML files, and cannot be imported. Likewise, exported XML files are incompatible with saved XML files, and cannot be opened.

5. Encryptor shall export valid XML.

   Before every release, Allen confirms that Encryptor exports valid XML using the World Wide Web Consortium (W3C) Markup Validation Service[1]. This is consistent with Allen's commitment to data portability (see Allen Analytical - About - Allen Analytical's commitment to data portability).

   The reproducible bug bounty is: Encryptor shall export valid XML.

The following features are not eligible for Allen's Reproducible Bug Bounty:

• Printing errors.

  Printing errors are not eligible for Allen's Reproducible Bug Bounty.

  Validation of Encryptor's print behavior is described in the following document: Encryptor - Validation - Printing.

  Briefly, the problem is:

  ...validation of Encryptor's print behavior is based on 38 columns per page by 48 rows calculated using the default line height of 1.5 and default font point size of 10 points, and the printable area of letter size paper when printing to a Samsung ML-1450. Changing the paper size or printing to a different printer affects the size of the printable area of the page, and the maximum number of columns or rows which may be printed.

  Although Allen is unable to test all possible print configurations, please report printing errors.

References:

Endnotes.

It is important to maintain a distinction between the document and the file throughout the discussion that follows because the contents of the document and the contents of the file may not be the same:

• The phrase "the document" refers to the "scratch pad" in memory. The document may or may not have been loaded from, or saved to, persistent storage such as a hard drive or flash drive, and the contents of the document may have changed since the document was last saved.
• The phrase "the file" refers to the file saved to persistent storage. The file is a record of the contents of the document when the document was last saved.

Encryptor's file save and quit behavior is based on the contents of the document, not the contents of the file. In every case where the file is not modified, the file contains private data if the document contained private data when it was last saved, i.e., private data WAS NOT cleared before saving.

If the user selects:

• Quit (⌘Q)
  • If the document has not been saved:
    • If the document has been edited:

      Present the "Don't save", "Cancel", or "Save" dialogue to the user. If the user selects:

      • Don't save

        Quit normally.

      • Cancel

        Cancel the Quit.

      • Save

        Save as described in "Save (⌘S)", below.

    • Otherwise, the document has not been edited.

      Quit normally.

  • Otherwise, the document has previously been saved.
    • If the document has been edited since it was last saved:

      Present the "Don't save", "Cancel", or "Save" dialogue to the user. If the user selects:

      • Don't save

        Quit normally. The file is not modified, and may contain private data.

      • Cancel

        Cancel the Quit.

      • Save

        Save as described in "Save (⌘S)", below.

    • Otherwise, the document has not been edited since it was last saved.
      • If the document contains private data:

        Present the "Clear private data...?" dialogue to the user. If the user selects:

        • Quit

          Quit without clearing private data. The file is not modified, and contains private data.

        • Cancel

          Cancel the Quit. The file is not modified, and contains private data.

      • Otherwise, the document contains no private data.

        Quit normally. The file is not modified, and does not contain private data.

• Save (⌘S)1
  • If the document has not been saved:
    • If the document contains private data:

      Present the "Clear private data...?" dialogue to the user. If the user selects:

      • Save

        Save the document without clearing private data. A file is created, and the file contains private data.

      • Cancel

        Cancel the Save, allowing the user to clear private data and then Save. A file is not created.

    • Otherwise, the document contains no private data.

      Save normally. A file is created, and the file does not contain private data.

  • Otherwise, the document has previously been saved.
    • If the document contains private data:

      Present the "Clear private data...?" dialogue. If the user selects:

      • Save

        Save without clearing private data. The file is modified, and contains private data.

      • Cancel

        Cancel the Save, allowing the user to clear private data and then Save. The file is not modified.

    • Otherwise, the document contains no private data.

      Save normally. The file is modified, and does not contain private data.

Endnotes.

The design goals of Encryptor include: "The user will retain control of their data." and "Encryptor will encourage multi-layered security, or 'defense in depth'."

Conforming passwords or other authentication tokens generated using Encryptor are indistinguishable from random text. As a result, the same memorable parsable tokens may be used to generate different conforming passwords for multiple web service providers without exposing the parsable tokens to discovery.

Although most web service providers store your password or other authentication tokens as a hash, or salted hash, which makes recovery difficult, some do not. In addition, transmitting your password or other authentication tokens over a non-secure connection exposes them to every web server between your computer and the web service provider.

Encryptor cannot solve these problems. Indeed, no action on your part can guarantee disclosure of the password or other authentication tokens you generate using Encryptor is prevented.

However, if inadvertent disclosure is a concern, for example because others have access to an unprotected file recording authentication details, several strategies may be helpful:

1. Filesystem or whole disk encryption.

   Allen recommends users of Encryptor use the features of the filesystem or operating system to secure saved documents using filesystem or whole disk encryption, for example: FileVault or a third-party utility such as TrueCrypt to encrypt a hard drive, or Disk Utility to create an encrypted partition. By default, saved documents created using Encryptor have a "eosx" extension, but users may elect to save XML or SQL documents created using Encryptor as "xml" or "sql" files.

2. Use a personal encryption algorithm which allows you to use memorable parsable tokens to generate conforming passwords or other authentication tokens and mark those parsable tokens as private data.

   Encryptor provides a way to mark parsable tokens as private data. Private data is handled specially by Encryptor (see Encryptor - Features - Private data).

   See Encryptor - Tutorial (T02) - Generating a conforming password for an example.

3. Modify the ciphertext generated by Encryptor as part of your personal encryption algorithm.

   For example:

   • Append or prepend a token known only to you to the ciphertext generated by Encryptor.

     For example, append or prepend "_d0G" or "2S!n" to the ciphertext generated by Encryptor. Adjust the token as necessary to satisfy the plaintext alphabet characteristics established by the web service provider. If the plaintext alphabet contains upper and lower case characters and decimal digits but no special characters, use "d0G" or "2Sn". If the plaintext alphabet contains upper and lower case characters and special characters, but no decimal digits, use "_dG" or "S!n".

   • Alter the ciphertext generated by Encryptor.

     For example, Encryptor generated the conforming password (see Encryptor - Tutorial (T07) - Encrypting plaintext):

     1TWaevTW

     However, both:

     11TTWWaaeevvTTWW
     111TTTWWWaaaeeevvvTTTWWW

     are also conforming passwords.

Throughout this document, the words "selected encryptor(s)" are used to describe controls which affect multiple encryptors. The words "selected encryptor" are used to describe controls which affect the first selected encryptor, even when more than one encryptor is selected.

Encryptor's user interface includes a number of elements and controls:

1. Search field.

   Enter a search term. Encryptor filters the list of encryptors as you type so that only encryptors with an account name, domain, or comment containing the search term are displayed.

2. List of encryptors.

   The list of encryptors created by the user.

   • Enter an account name in field "Name".

     The default account name is "username".

   • Enter a domain in field "Domain".

     If no encryptor is selected, the default domain is "domain".

     If an encryptor is selected, the new encryptor will have the same domain as the domain of the selected encryptor. This is useful when creating several accounts at a time, for example, if you are an administrator creating passwords for users of your site.

   • Enter a comment in field "Comment".

     Comments are not required, but useful to store the names of businesses, for example, which cannot be readily determined by examining the domain.

   Fields "Added" and "Modified" display the date the encryptor was created and the date the encryptor was last modified, respectively. These fields are not editable.

3. New Encryptor button.

   Click the New Encryptor button to create a new encryptor, or select "File > New Encryptor" (⇧⌘N).

4. Delete Encryptor button.

   Click the Delete Encryptor button to delete the selected encryptor(s), or select "File > Delete Encryptor" (⌘D).

5. Clear Private Data button.

   Click the Clear Private Data button to clear private data (see Encryptor - Features - Private data).

6. Encryptor Preferences button.

   Click the Encryptor Preferences button to change the preferences for the selected encryptor.

7. Confirm Ciphertext button.

   Click the Confirm Ciphertext button to open the confirmation dialogue window.

8. Cipher type button.

   Click the Cipher type button to change the cipher type for the selected encryptor(s). Select one of the following cipher types:

   1. None.
   2. Keyword substitution.
   3. Vigenère.
   4. Autokey.
   5. Running key.

   The default cipher type is "Vigenère".

   Changing the cipher type updates the user interface:

   • Cipher type "None".

     Fields "Keyword", "Key", and "Ciphertext" are disabled.

   • Cipher type "Keyword substitution".

     Field "Key" is disabled.

   This does not prevent the user from storing data in these fields. First, select a cipher type that uses a keyword and key, and generates ciphertext: "Vigenère", "Autokey", or "Running key". Enter the keyword and key, then change the cipher type to "None" or "Keyword substitution". Encryptor will retain the keyword and key entered.

9. Field "Keyword".

   Enter the keyword for the selected encryptor(s). The keyword is a parsable token (see Encryptor - About - Parsable tokens).

   Field "Keyword" is disabled for cipher type "None".

10. Remember Keyword button.

    Click the Remember Keyword button to mark the keyword as private data (see Encryptor - Features - Private data):

    • Click the Remember Keyword button to reveal the "Locked" icon and lock the keyword(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Keyword button to reveal the "Unlocked" icon and unlock the keyword(s) for the selected encryptor(s), marking the keyword(s) as private data.
11. Rotate Keyword Left button.

    Click the Rotate Keyword Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the keyword to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Keyword Left button is enabled if the keyword is marked as private data, and disabled otherwise.

12. Rotate Keyword Right button.

    Click the Rotate Keyword Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the keyword to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Keyword Right button is enabled if the keyword is marked as private data, and disabled otherwise.

13. Field "Unique, valid keyword".

    This field displays the unique, valid keyword (see Encryptor - About - Intermediate variables). The unique, valid keyword cannot be changed by entering a value in this field, but only by changing the keyword.

14. Field "Key".

    Enter the key for the selected encryptor(s). The key is a parsable token (see Encryptor - About - Parsable tokens).

    Field "Key" is disabled for cipher types "None" and "Keyword substitution".

15. Remember Key button.

    Click the Remember Key button to mark the key as private data (see Encryptor - Features - Private data):

    • Click the Remember Key button to reveal the "Locked" icon and lock the key(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Key button to reveal the "Unlocked" icon and unlock the key(s) for the selected encryptor(s), marking the key(s) as private data.
16. Rotate Key Left button.

    Click the Rotate Key Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the key to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Key Left button is enabled if the key is marked as private data, and disabled otherwise.

17. Rotate Key Right button.

    Click the Rotate Key Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the key to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Key Right button is enabled if the key is marked as private data, and disabled otherwise.

18. Field "Valid key".

    This field displays the valid key (see Encryptor - About - Intermediate variables). The valid key cannot be changed by entering a value in this field, but only by changing the key.

19. Field "Plaintext".

    Enter the plaintext for the selected encryptor(s). The plaintext is a parsable token (see Encryptor - About - Parsable tokens).

20. Remember Plaintext button.

    Click the Remember Plaintext button to mark the plaintext as private data (see Encryptor - Features - Private data):

    • Click the Remember Plaintext button to reveal the "Locked" icon and lock the plaintext(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Plaintext button to reveal the "Unlocked" icon and unlock the plaintext(s) for the selected encryptor(s), marking the plaintext(s) as private data.
21. Rotate Plaintext Left button.

    Click the Rotate Plaintext Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the plaintext to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Plaintext Left button is enabled if the plaintext is marked as private data, and disabled otherwise.

22. Rotate Plaintext Right button.

    Click the Rotate Plaintext Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the plaintext to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Plaintext Right button is enabled if the plaintext is marked as private data, and disabled otherwise.

23. Field "Valid plaintext".

    This field displays the valid plaintext (see Encryptor - About - Intermediate variables). The valid plaintext cannot be changed by entering a value in this field, but only by changing the plaintext.

24. Field "Ciphertext".

    This field displays the ciphertext generated by Encryptor.

    Field "Ciphertext" is disabled for cipher type "None".

25. Use Keychain button.

    Click the Use Keychain button to allow Encryptor to create, modify, or delete keychain item(s) for the selected encryptor(s) (see Encryptor - Features - Mac OS X Keychain integration).

26. Synchronize Keychain Item button.

    Click the Synchronize Keychain Item button to create a keychain item for the selected encryptor or change the password for an existing keychain item.

    The Synchronize Keychain Item button is disabled when the keychain is not in use for the selected encryptor, or when the keychain is in use and the password for the selected encryptor matches the password for the keychain item.

    The icon on the Synchronize Keychain Item button is an "Add" icon if there is no keychain item for the selected encryptor, and changes from an "Add" icon to a "Refresh" icon if there is a keychain item for the selected encryptor.

    When the user makes a change which changes the ciphertext for the selected encryptor, for example a change to the plaintext alphabet characteristics or a parsable token, the Synchronize Keychain Item button is enabled. Clicking the Synchronize Keychain Item button will prompt the user to change the password for the keychain item.

27. Delete Keychain Item button.

    Click the Delete Keychain Item button to delete the keychain item for the selected encryptor.

    The Delete Keychain Item button is disabled when there is no keychain item for the selected encryptor, and enabled when there is a keychain item for the selected encryptor.

28. Complexity requirements.

    Encryptor provides visual feedback to the user to allow the user to easily confirm the plaintext (for cipher type "None") or ciphertext (for all other cipher types) satisfies the complexity requirements specified by the user via application and encryptor preferences (see Encryptor - About - Complexity requirements).

29. Status.

    Encryptor reports various status messages here. For example, Encryptor reports "Created a keychain item for..." when it creates a keychain item, or "Found a match for this [parsable token]" when it finds a match for the complexity requirements for the selected encryptor by rotating the parsable token.

Allowed character set

The combination of upper and lower case characters, decimal digits, and special characters allowed by the web service provider. Conforming passwords include only characters from the allowed character set.

Cipher type

The cipher type.

Complexity requirements

The complexity requirements established by the web service provider, such as: "must be at least eight characters", "must have at least one capital letter", and "must not contain more than three consecutive identical characters". Conforming passwords satisfy the complexity requirements.

Conforming password

A password which meets the minimum requirements established by a web service provider.

Key column

The first column of the tabula.

Personal encryption algorithm

The purpose of Encryptor is to allow users to combine something they have, i.e., a document recording their choices, with something they know, i.e., their personal encryption algorithm.

Encryptor records the details of password generation which are outside your control as a convenience to you and uses parsable tokens which you specify to encipher plaintext. This is something you have.

Encryptor supports the development and use of a personal encryption algorithm known only to you. Your personal encryption algorithm is the method by which the details of password generation which are outside your control and parsable tokens you specify are combined to generate a conforming password. This is something you know.

Tabula

The tabula recta (literally "square table").

The tabula recta is a latin square, specifically, a special case of a reduced latin square.

The tabula recta is generated from the ciphertext alphabet. The first row of the tabula is identical to the ciphertext alphabet. Each succeeding row of the tabula is shifted one character to the left from the preceding row. The number of rows and columns in the tabula recta is identical to the number of characters in the plaintext or ciphertext alphabet.

Valid

When referring to the intermediate variables unique, valid keyword, valid key, and valid plaintext (see Encryptor - About - Intermediate variables), valid characters are those in the plaintext alphabet.

Web service provider

A provider of services which require the use of the Internet or other private network. The term "web service provider" is used because "Internet Service Provider" (ISP) has a widely-used and established meaning.

URL

Uniform Resource Locator[1].

References:

This list is a list of published references which are cited in the documentation for Encryptor.

This list is not a comprehensive list of all references cited in the documentation for Encryptor. Allen does not consider documentation to which access is controlled exclusively by the originator to be published because this documentation is ephemeral and may be revised at any time. Frequently, the web service provider or other originator revises references without notifying the user that there has been a change, documenting what has changed, or following document control practices which were standard long before the advent of the Internet.

This does not mean that references accessible via the Internet, or only via the Internet, are unreliable. On the contrary, many of them are definitive. However, there is a qualitative difference between a Request for Comments (RFC) published by the Internet Engineering Task Force (IETF) as a technical document which defines a standard, and the user-level self-help available from Google or Facebook. The IETF states[1]: "Published RFCs never change."

Neither Google nor Facebook make, or indeed can make, such a claim about their user-level self-help, which changes frequently and without notice. As a result, the most reliable record of these requirements is a screen capture. In general, Allen considers the screen capture reliable and and the document to which the screen capture refers to be ephemeral. As a result, Allen considers the screen capture to be published, but not the document to which the screen capture refers.

References:

The purpose of this tutorial is to demonstrate how to use Encryptor to generate a password. For the purposes of this example, the password will not be a conforming password (see Encryptor - Support - Glossary). Generating a conforming password would require a focus on the minimum requirements established by a web service provider and not the use of Encryptor to generate a password.

1. Launch Encryptor.

   Launch Encryptor.

2. Create a new encryptor.

   Click the New Encryptor button to create a new encryptor, or select "File > New Encryptor" (⇧⌘N).

3. Change the encryptor's preferences.

   When a new encryptor is created, Encryptor will set the encryptor's preferences using the application preferences. However, the plaintext alphabet characteristics and ciphertext complexity requirements established by the web service provider may require the user to change the encryptor's preferences. If necessary, click the Encryptor Preferences button to change the encryptor's preferences.

   Encryptor's default plaintext alphabet contains 95 characters: the uppercase letters A through Z, lowercase letters a through z, decimal digits 0 through 9, and graphic characters of the 7-bit ISO-8859-1 character set (the ASCII character set), including space, which is a "...normally non-printing graphic character..." (see Encryptor - About - Intermediate variables).

   Encryptor's default ciphertext complexity requirements require a minimum length of eight (8) characters, but no restriction on maximum length, and the use of upper case letters, lower case letters, decimal digits, special characters, but no regex (regular expression) mask.

   Accept the default plaintext alphabet characteristics and ciphertext complexity requirements. Click the Save button (Encryptor Preferences).

4. Enter the account name.

   Enter the account name: "test". Press the "Enter" key or tab to the next field.

   Although the Mac OS X Keychain Services API provides a method for determining the user portion of a URL conforming to RFC 1808, Encryptor uses the account name entered as field "Name" by the user (see Encryptor - Features - Mac OS X Keychain integration).

5. Enter the domain.

   Enter the domain: "http://www.example.com". Press the "Enter" key or tab to the next field.

   Encryptor determines the scheme, server name, port, and path by parsing field "Domain" entered by the user as a URL (see Encryptor - Features - Mac OS X Keychain integration).

6. Enter a comment.

   Enter any comment (here "Example"), or no comment. Press the "Enter" key or tab to the next field.

   Comments are not required, but useful to store the names of businesses, for example, which cannot be readily determined by examining the domain.

7. Select the cipher type.

   Select the cipher type: "Vigenère". Tab to the next field.

   The cipher type determines how Encryptor encrypts plaintext using the valid key (see Encryptor - About - Intermediate variables).

8. Enter the keyword.

   Enter the keyword: "keyword". Press the "Enter" key or tab to the next field.

   Because the keyword is a parsable token (see Encryptor - About - Parsable tokens), Encryptor immediately generates the unique, valid keyword and displays it in field "Unique, valid keyword". The unique, valid keyword cannot be changed by entering a value in this field, but only by changing the keyword.

9. Enter the key.

   Enter the key: "key". Press the "Enter" key or tab to the next field.

   Because the key is a parsable token (see Encryptor - About - Parsable tokens), Encryptor immediately generates the valid key and displays it in field "Valid key". The valid key cannot be changed by entering a value in this field, but only by changing the key.

10. Enter the plaintext.

    Enter the plaintext: "plaintext". Press the "Enter" key or tab to the next field.

    Because the plaintext is a parsable token (see Encryptor - About - Parsable tokens), Encryptor immediately generates the valid plaintext and displays it in field "Valid plaintext". The valid plaintext cannot be changed by entering a value in this field, but only by changing the plaintext.

    Because we have provided the valid key and valid plaintext required for cipher type "Vigenère", Encryptor immediately generates the ciphertext and reports that it does not satisfy the ciphertext complexity requirements: the ciphertext does not use upper case characters or decimal digits (indicated by a red cross next to those requirements).

    Enter the plaintext: "Plaintext:". Press the "Enter" key or tab to the next field.

    Encryptor immediately generates the ciphertext and reports that it satisfies all of the ciphertext complexity requirements (indicated by a green tick mark next to all requirements).

The purpose of this tutorial is to demonstrate how to use Encryptor to generate a conforming password. See Encryptor - Tutorial (T01) - Generating a password for more general information about using Encryptor to generate a password.

For the purposes of this tutorial, we will generate a conforming password for an Apple ID. The authentication details (i.e., the email address, domain, and password) used in this tutorial are for the purposes of example only, and were not used by Allen to register as an Apple developer.

1. Navigate to the Apple Developer registration page.

   Navigate to the Apple Developer registration page to register as an Apple Developer. Click "Get Started".

2. Select "Create an Apple ID".

   Select "Create an Apple ID" to create an Apple ID. Click "Continue" (not shown) to continue.

3. Enter an email address.

   Enter an email address1.

4. Enter the account name, domain, and a comment for this encryptor.

   Launch Encryptor. Enter the account name, domain, and a comment for this encryptor2. Press the "Enter" key or tab to the next field.

   The personal encryption algorithm in use in this example is based on field "Comment".

5. Change the encryptor's preferences.

   When a new encryptor is created, Encryptor will set the encryptor's preferences using the application preferences. However, the plaintext alphabet characteristics and complexity requirements established by Apple require us to change the encryptor's preferences. Click the Encryptor Preferences button to change the encryptor's preferences.

   The complexity requirements established by Apple are published on the Apple Developer Registration page. This is a good practice.

   The first requirement applies to all "personal profile information", including the password, and limits the plaintext alphabet to the 7-bit characters in the ISO-8859-1 character set:

   Important: Your personal profile information should be entered in English and without using diacritical characters (for example: ü, é, ñ)

   All other requirements apply specifically to the password.

   Password must:
   - Have at least one capital letter
   - Have at least one number
   - Not contain more than 3 consecutive identical characters
   - Not be the same as the account name
   - Be at least 8 characters

   1. Set the plaintext alphabet characteristics.

      Some plaintext alphabet characteristics established by Apple are inferred from the complexity requirements: the plaintext alphabet includes upper case letters and decimal digits. However, Apple does not explicitly state the plaintext alphabet includes only upper case letters and decimal digits, and it would be unreasonable to assume that it does. Therefore, to ensure the potential search space is as large as Apple allows, the plaintext alphabet also includes lower case letters.

      Apple does not disclose the allowed special character set, but does not require the use of special characters. This is a good practice3. Although most web service providers require the use of special characters, many web service providers do not disclose the allowed special character set until after the user selects a password, confirms the password, and goes through a "password strength" check (see Encryptor - Support - Determining the allowed special character set.).

      The plaintext alphabet characteristics we will use are: "Use 7-bit character set", "Upper case characters", "Lower case characters", and "Decimal digits" (see Encryptor - About - Plaintext alphabet characteristics). We will delete the special character set.

      • Ensure options "Use 7-bit character set", "Upper case characters", "Lower case characters", and "Decimal digits" are checked.
      • Delete the special character set. Press the "Enter" key or tab to the next field. The special character set has been deleted if the text field labeled "Special character set" is empty, i.e., it contains no characters, including space, which is a "...normally non-printing graphic character...".
   2. Set the ciphertext complexity requirements.

      Encryptor supports several simple checks for ciphertext complexity requirements. Although we could use a regex mask for all of the complexity requirements established by Apple (see Using a regex mask for all of the complexity requirements established by Apple), we will use the simple checks for all of the complexity requirements but one4, for which we will use a regex mask.

      The simple checks we will use are: "Use minimum length", "Use upper case characters", "Use lower case characters", and "Use decimal digits" (see Encryptor - About - Complexity requirements).

      To implement the check that the password not contain more than 3 consecutive identical characters, we will use a more complex check: "Use regex mask" and the following regex mask: "(?!^.*([A-Za-z0-9])\1{3,})^.*[A-Za-z0-9].*$" (without the double quotes).

      • If necessary, drag the slider to change the minimum length to eight (8). The default minimum length is eight (8).
      • Ensure options "Use minimum length", "Use upper case characters", "Use lower case characters", and "Use decimal digits" are checked. These options are checked by default. Uncheck option "Use special characters"; the plaintext alphabet contains no special characters.
      • Check option "Use regex mask". Enter the expression: "(?!^.*([A-Za-z0-9])\1{3,})^.*[A-Za-z0-9].*$" (without the double quotes) in the text field under this option.
   3. Save

      Click the Save button (Encryptor Preferences).

6. Enter the keyword for this encryptor.

   Enter the keyword for this encryptor.

   The personal encryption algorithm in use in this example is based on field "Comment", and will make use of one of the most common books in existence: the King James version of the Bible, although any book could be used, a similar method, or indeed any other reproducible method: the keyword is the complete text of the book, chapter, and verse corresponding to the first three letters of the text entered in field "Comment": "app".

   The letter "a" is the first letter of the alphabet, and corresponds to the first book of the Bible: Genesis. The second letter "p" is the 16th letter of the alphabet, and corresponds to chapter 16. The third letter "p" corresponds to verse 16, which is the last verse of chapter 16 of the book of Genesis.

   Our keyword is the complete text of Genesis 16:16: "And Abram was fourscore and six years old, when Hagar bare Ishmael to Abram."

   If necessary, for example because the third letter of the text entered in field "Comment" was the letter "r" (for "April Communications, LLC") or the letter "t" (for "Aptive Measurement Incorporated"), the personal encryption algorithm in use in this example requires we "wrap around" the verses in chapter 16 to verse 1, which corresponds to the letter "q" which follows the letter "p" in the alphabet. The letter "r" therefore corresponds to verse 2 and the letter "t" to verse 4. A similar method could be used to "wrap around" the chapters or books if necessary.

   Enter "And Abram was fourscore and six years old, when Hagar bare Ishmael to Abram." in field "Keyword" and click the Remember Keyword button to the right to reveal the "Unlocked" icon (see Encryptor - Tutorial (T04) - Clearing private data). We do not need Encryptor to remember the keyword for us because we can recover it at any time based on the personal encryption algorithm.

   Press the "Enter" key or tab to the next field.

7. Enter the key for this encryptor.

   Enter the key for this encryptor.

   The personal encryption algorithm in use in this example is based on field "Comment". The second word of field "Comment" is the key: "Developer".

   Enter "Developer" in field "Key". We do not need Encryptor to remember the key for us because we can recover it at any time based on the personal encryption algorithm, but there is an advantage to not marking the key as private data which will become apparent later.

   Press the "Enter" key or tab to the next field.

8. Enter the plaintext for this encryptor.

   Enter the plaintext for this encryptor.

   The personal encryption algorithm in use in this example is based on field "Comment", and provides both the keyword and key, but not the plaintext. We unlocked the keyword, and will be prompted to delete it before we Save or Quit. After we delete the keyword, the information stored by Encryptor alone cannot be used to re-create the ciphertext. As a result, for the purposes of this example, it does not matter what plaintext we enter. We can enter any arbitrary plaintext which results in a conforming password.

   Enter "password" in field "Plaintext". Press the "Enter" key or tab to the next field.

   Encryptor immediately generates the ciphertext and reports that it satisfies the ciphertext complexity requirements: the ciphertext is a conforming password. However, if this were not the case, we could enter any arbitrary plaintext which would result in a conforming password. We require Encryptor to store the plaintext.

   Although we may not need Encryptor to store the plaintext for this encryptor, there is an advantage to not marking the plaintext as private data: when we clear private data, Encryptor deletes the keyword used to generate the conforming password for our Apple ID, and the resulting ciphertext is also a conforming password (see Encryptor - Tutorial (T04) - Clearing private data).

   The obvious advantage is the ability to ensure anyone gaining access to an unprotected file will not be able to re-create the conforming password, although it does require careful selection of the plaintext. For all practical purposes, we create the illusion that no keyword was used, when this is in fact not the case.

At this point, the tutorial is complete. However, this tutorial provides a sound basis for demonstrating several other features of Encryptor: Encryptor - Tutorial (T03) - Using the confirmation dialogue window, Encryptor - Tutorial (T04) - Clearing private data, and Encryptor - Tutorial (T05) - Creating a keychain item.

Endnotes.

This tutorial is based on tutorial: Encryptor - Tutorial (T02) - Generating a conforming password, and uses the same plaintext alphabet characteristics, complexity requirements, and parsable tokens.

Previously:

• We generated a conforming password for an Apple ID (see Encryptor - Tutorial (T02) - Generating a conforming password).

We now want to confirm the password.

Encryptor provides visual feedback to the user to allow the user to easily confirm the parsable tokens used to generate ciphertext and the ciphertext generated using the parsable tokens match those of the selected encryptor.

When using the confirmation dialogue window:

• A green tick mark means the parsable token or ciphertext in the confirmation dialogue window matches that of the selected encryptor.
• A red cross means the parsable token or ciphertext in the confirmation dialogue window DOES NOT match that of the selected encryptor.

The purpose of the confirmation dialogue window, i.e., the "Confirm ciphertext" window, is to detect typing mistakes made when entering the parsable tokens used to generate ciphertext. Using it is recommended when parsable tokens are typed directly into fields "Keyword", "Key", and "Plaintext", especially if any of them will be marked as private data, which is handled specially by Encryptor.

To confirm the parsable tokens used to generate ciphertext:

1. Open the confirmation dialogue window.

   Click the Confirm Ciphertext button to open the confirmation dialogue window (not shown).

2. Enter the keyword to confirm.

   Enter "And Abram was fourscore and six years old, when Hagar bare Ishmael to Abram." in field "Keyword". Press the "Enter" key or tab to the next field. Encryptor reports the keyword matches the keyword of the selected encryptor (not shown).

3. Enter the key to confirm.

   Enter "Developer" in field "Key". Press the "Enter" key or tab to the next field. Encryptor reports the key matches the key of the selected encryptor (not shown).

4. Enter the plaintext to confirm.

   Enter "password" in field "Plaintext". Press the "Enter" key or tab to the next field. Encryptor reports the plaintext matches the plaintext of the selected encryptor (not shown).

Encryptor immediately generates the ciphertext using the parsable tokens entered in the confirmation dialogue window and the same plaintext alphabet characteristics as the selected encryptor and reports that it matches the ciphertext of the selected encryptor (see Figure T03A - Using the confirmation dialogue window).

When creating an account or changing a password, most web service providers require the user to select a password, then confirm the password selected. Using the confirmation dialogue window conveniently allows you to copy and paste the ciphertext from the confirmation dialogue window (provided it matches the ciphertext of the selected encryptor) and then the main window into the "Password" and "Confirm password" text fields in use by a web service provider, and gain assurance that the password entered in the "Password" text field matches the password entered in the "Confirm password" text field before clicking "Submit".

This tutorial is based on tutorial: Encryptor - Tutorial (T02) - Generating a conforming password, and uses the same plaintext alphabet characteristics, complexity requirements, and parsable tokens.

Previously:

• We generated a conforming password for an Apple ID (see Encryptor - Tutorial (T02) - Generating a conforming password).
• We confirmed the password (see Encryptor - Tutorial (T03) - Using the confirmation dialogue window).

We have now created an Apple ID, and want to clear private data (see Encryptor - Features - Private data) to delete the keyword before we Save.

To clear private data:

1. Click the Clear Private Data button.

   Click the Clear Private Data button.

2. Encryptor deletes all parsable tokens marked as private data.

   Encryptor deletes all parsable tokens marked as private data1,immediately generates the ciphertext resulting from the deletion (herein the "resulting ciphertext"), and reports that the resulting ciphertext satisfies the ciphertext complexity requirements. The resulting ciphertext is also a conforming password.

Endnotes.

This tutorial is based on tutorial: Encryptor - Tutorial (T02) - Generating a conforming password, and uses the same plaintext alphabet characteristics, complexity requirements, and parsable tokens.

Previously:

• We generated a conforming password for an Apple ID (see Encryptor - Tutorial (T02) - Generating a conforming password).
• We confirmed the password (see Encryptor - Tutorial (T03) - Using the confirmation dialogue window).

We have now created an Apple ID, and want to create a keychain item for this encryptor (see Encryptor - Features - Mac OS X Keychain integration).

To create a keychain item for this encryptor:

1. Click the Synchronize Keychain Item button.

   Click the Synchronize Keychain Item button.

2. Encryptor displays an alert.

   Encryptor displays an alert.

   The alert details the information that will be used to create the keychain item. Encryptor determines the scheme, server name, port, and path by parsing field "Domain" entered by the user as a URL (see Encryptor - Features - Mac OS X Keychain integration).

   Review the information to ensure it is correct1 before clicking the Create Keychain Item button.

3. Click the Create Keychain Item button to create a keychain item.

   Click the Create Keychain Item button to create a keychain item.

4. Encryptor reports that it created a keychain item for this encryptor.

   Encryptor reports that it created a keychain item for this encryptor.

   When the keychain item is created, the icon on the Synchronize Keychain Item button changes from an "Add" icon to a "Refresh" icon. The Synchronize Keychain Item button is disabled because the keychain item was just created and is therefore up-to-date, that is, the password for this encryptor matches the password for the keychain item. When the user makes a change which changes the ciphertext for this encryptor, for example a change to the plaintext alphabet characteristics or a parsable token, the Synchronize Keychain Item button is enabled. Clicking the Synchronize Keychain Item button will prompt the user to change the password of the keychain item.

   Likewise, the Delete Keychain Item button is disabled when no keychain item for this encryptor exists, and enabled when a keychain item exists. Clicking the Delete Keychain Item button when a keychain item exists will prompt the user to delete the keychain item for the selected encryptor.

5. Confirm Keychain Access has an entry for this encryptor, and that is it correct.

   Confirm Keychain Access has an entry for this encryptor, and that is it correct.

   Launch Keychain Access and confirm it has an entry for this encryptor. The information stored by Keychain Access should match the information which was used to create the keychain item.

The authentication details (i.e., the email address, domain, and password) used in this tutorial are for the purposes of example only, and were not used by Allen to register as an Apple developer. However, I have a valid Apple ID and have used versions of Encryptor to generate my passwords for several years.

The authentication details for my Apple ID and the corresponding keychain item differ from the authentication details used in our example. In addition to my personal Apple ID and password, when creating a keychain item I entered the specific URL in field "Domain" for which the keychain item will be requested when signing in: https://daw.apple.com.

Determining the correct URL is sometimes challenging, as the registration and log in links in use by some web service providers have no relationship to each other, and frequently change. It is so they may be changed at any time that the use of fields "Name" or "Domain" in a personal encryption algorithm is not recommended, unless you also want to require a change of password at this time.

After creating a keychain item for my current Apple ID, Safari prompts me to allow access to the keychain item I created when I sign in to Apple Developer. Click "Allow" or "Always Allow" (recommended) to allow Safari to access the keychain item.

Some popular Mac OS X applications do not natively support Mac OS X Keychain Services, for example, Firefox. See Encryptor - A note to Firefox users.

Endnotes.

Web service providers commonly implement password recovery options in the event a user forgets their password. The most common password recovery option is the use of challenge questions1 and answers. However, the use of challenge questions and answers provides little assurance the person providing the answer is, in fact, the user who created the account. By necessity, the web service provider must ask a question to which there is only one answer, and the answer must be memorable and factual. As a result, many web service providers ask the same questions.

These examples are taken directly from a list of challenge questions I have compiled over several years. Several web service providers asked each of the following questions:

• What is the name of your first school?
• What was the name of your elementary school?
• What was the name of your high school?
• What was the name of your first pet2?
• What is the name of the city or town where you were born?
• What is the zip code of the address where you grew up?
• In what city was your high school?

Obviously, some of these questions are different ways of asking for the same information. For example, someone knowing the zip code of the address where you grew up likely knows the name of the city or town where you were born, and someone knowing what the name of your high school was likely knows what city it was in.

In many cases, the answers to these challenge questions can be determined by review of the user's Facebook page or LinkedIn profile, or indeed any of the many other sources on the Internet which hemorrhage the private details of our lives. As a result, the use of challenge questions provides little assurance that the person providing the answer is, in fact, the user who created the account.

Several strategies have been proposed to improve the security of challenge questions:

• Some web service providers allow the user to choose a question and answer.

  This has the advantage of not being discoverable by an adversary going through the same account creation process as the user. However, this requires the user to remember not only a password, but also the answer to a challenge question. If the question is suitably obscure, it may provide a measure of assurance. However, if the question is some variant of one of the many challenge questions in common use, it is probably less secure than the password which was forgotten.

• Some users lie.

  This has the advantage of not being discoverable by review of the user's Facebook page or LinkedIn profile. However, this requires the user to remember the false information provided. Some users go so far as to create an alternate identity to conceal the private details of their lives, but as this identity is used more and more, it takes on a life of its own and itself becomes vulnerable to discovery.

• Some users create a new account with a new password when they cannot remember the authentication details for their existing account.

  This has the advantage of not requiring the user to remember anything. However, over the past several years it has become increasingly common for web service providers to associate an email address with an account. Attempting to create an account with the same email address causes the web service provider to attempt to authenticate the user by sending an email to the email account in question, with instructions on resetting the password, the success of which may rely on the user remembering the answers to their challenge questions.

• Some web service providers support multiple factor authentication, for example, by sending a one-time access code to the user's phone or email address, in the event the user forgets their password.

  This has the advantage that the user must be in possession of the device or email account in question. However, it requires the user to hemorrhage even more information, which may be undesirable if the user wants to retain as much privacy as possible.

  For example, Google periodically interrupts the sign in process to remind me that I haven't provided a phone number for password recovery, which I would also be able to use for Google's "two-step verification" process. However, I do not need to provide a phone number to access Google's services, and I have no desire to provide a phone number to Google. I certainly have no desire to provide Google with my cell phone number, which is the most logical number to provide, since it is almost always in reach. I simply do not trust Google not to abuse access to my cell phone. Google has long been in the business of aggregating information for targeted advertising, and I have no desire to provide more than the absolute minimum information necessary to access Google's services. Google's recent declaration that Google+ is an "identity service" has validated my decision.

One of the design goals of Encryptor was: Encryptor will solve one of the most common problems with passwords, memorability, by allowing the user to use memorable parsable tokens to generate conforming passwords or other authentication tokens (see Encryptor - About - What makes Encryptor different from other password generators or managers?).

As a result, Encryptor may be used to generate the answers to challenge questions, ensuring the answer is unique to each web service provider.

For reasons which are discussed in detail below, our personal encryption algorithm for generating the answers to all challenge questions is:

1. Change the encryptor's preferences so the plaintext alphabet includes only upper and lower case characters and decimal digits.
2. Do not to enter a keyword.
3. Enter the challenge question in field "Key".
4. Enter the answer to the challenge question in field "Plaintext".

This tutorial accompanies tutorial: Encryptor - Tutorial (T02) - Generating a conforming password.

Previously:

• We generated a conforming password for an Apple ID (see Encryptor - Tutorial (T02) - Generating a conforming password).
• We confirmed the password (see Encryptor - Tutorial (T03) - Using the confirmation dialogue window).
• We created a keychain item (see Encryptor - Tutorial (T05) - Creating a keychain item).
• We cleared private data (see Encryptor - Tutorial (T04) - Clearing private data).

We now want to generate the answer to the challenge question: "What was the name of your first pet?"

1. Create a new encryptor.

   Select "File > New Encryptor" (⇧⌘N) to create a new encryptor.

2. Enter the account name, domain, and a comment for this encryptor.

   Enter the account name, domain, and a comment for this encryptor3. For this example, enter "Challenge question" in field "Comment".

   Entering a comment such as "challenge" or "Challenge question" will make it possible to easily filter encryptors.

   Press the "Enter" key or tab to the next field.

3. Change the encryptor's preferences.

   When a new encryptor is created, Encryptor will set the encryptor's preferences using the application preferences. However, because the answers to challenge questions will likely contain only upper and lower case characters and decimal digits, it is advantageous to change the encryptor's preferences so the plaintext alphabet includes only these characters. Click the Encryptor Preferences button to change the encryptor's preferences.

   1. Set the plaintext alphabet characteristics.

      The answers to challenge questions will likely contain only upper and lower case characters and decimal digits.

      The plaintext alphabet characteristics we will use are: "Use 7-bit character set", "Upper case characters", "Lower case characters", and "Decimal digits" (see Encryptor - About - Plaintext alphabet characteristics). We will delete the special character set.

      • Ensure options "Use 7-bit character set", "Upper case characters", "Lower case characters", and "Decimal digits" are checked.
      • Delete the special character set. Press the "Enter" key or tab to the next field. The special character set has been deleted if the text field labeled "Special character set" is empty, i.e., it contains no characters, including space, which is a "...normally non-printing graphic character...".
   2. Set the ciphertext complexity requirements.

      Because we are not generating a conforming password we do not need to satisfy complexity requirements (see Encryptor - About - Complexity requirements). Ensure options "Use minimum length", "Use upper case characters", "Use lower case characters", "Use decimal digits", and "Use special characters" are not checked. These options are checked by default. Ensure option "Use maximum length" is not checked. This option is not checked by default.

   3. Save

      Click the Save button (Encryptor Preferences).

4. Enter the keyword for this encryptor.

   The keyword is used to generate the unique, valid keyword, which is used to generate the ciphertext alphabet. If no keyword is provided, the tabula is based on the unmodified plaintext alphabet (see Encryptor - About - Parsable tokens).

   It is to our advantage to use a tabula based on the unmodified plaintext alphabet because the tabula is the easiest to construct using pencil-and-paper methods (see Encryptor - About - What makes Encryptor different from other password generators or managers?). Also, when printed, a tabula based on the unmodified plaintext alphabet containing only upper and lower case characters and decimal digits is re-usable for multiple challenge questions, or indeed multiple account names and domains.

   Do not enter a keyword. No keyword is needed.

   Press the "Enter" key or tab to the next field.

5. Enter the key for this encryptor.

   Enter the key for this encryptor.

   The personal encryption algorithm in use in this example uses the challenge question as the key.

   Enter "What was the name of your first pet?" in field "Key". Click the Remember Key button to the right of field "Key" to mark it as private data. Because we are using the challenge question as the key, we do not need Encryptor to remember the key for us. When required by the web service provider, we enter the challenge question in field "Key".

   Press the "Enter" key or tab to the next field.

6. Enter the plaintext for this encryptor.

   Enter the plaintext for this encryptor.

   Enter "Caesar O'Toole" in field "Plaintext". Press the "Enter" key or tab to the next field.

   Encryptor immediately generates the ciphertext "iHEIWRGMVSYE". The ciphertext is the enciphered answer to the challenge question, and can be provided to the web service provider without disclosing the plaintext. If desired, with careful selection of parsable tokens the user can ensure the enciphered answer is unique for each account name and domain.

   Click the Remember Plaintext button to the right of field "Plaintext" to mark it as private data. Because we are using the answer to the challenge question as the plaintext, and we know the answer, we do not need Encryptor to remember the plaintext for us. We can recover it at any time based on our personal encryption algorithm. Also, we may re-use this encryptor to generate the answers to other challenge questions for this account name and domain, or indeed multiple account names and domains.

   Click the Use Keychain button to the right of field "Ciphertext" so that Encryptor will not report that the password for the keychain item corresponding to this account name and domain is not up-to-date. Although this isn't required, it is a good practice.

7. Save the file.

   Encryptor warns us that the file contains private data. Click Cancel to cancel the Save and clear private data before saving.

8. Clear private data.

   Click the Clear Private Data button.

   The key and plaintext are deleted. Because we have chosen the "Vigenère" cipher type, Encryptor cannot generate ciphertext without a key and the ciphertext is also deleted.

9. Save the file.

   Encryptor does not warn us that the file contains private data because private data was deleted before saving (see Encryptor - Support - Features eligible for Allen's Reproducible Bug Bounty).

Endnotes.

This tutorial is based on tutorial: Encryptor - Tutorial (T02) - Generating a conforming password (herein "Tutorial T02"), and uses the same plaintext alphabet characteristics, cipher type, and parsable tokens.

The purpose of this tutorial is to demonstrate how to encrypt plaintext using pencil-and-paper methods to reproduce the ciphertext Encryptor generates. This tutorial is specific to cipher types "Vigenère", "Autokey", and "Running key", which use a tabula. Cipher type "Keyword substitution" does not use a tabula, although the method of encryption is similar (see Encryptor - Tutorial (T08) - Encrypting plaintext (Keyword substitution)).

Before discussing how Encryptor generates ciphertext, it is first necessary to establish some conventions, several of which are basic to cryptography in general. These conventions will be used throughout this tutorial:

• The plaintext alphabet is written above the first row of the tabula (see Encryptor - About - Intermediate variables).
• The first row of the tabula is identical to the ciphertext alphabet (see Encryptor - About - Intermediate variables).
• The first column of the tabula is the key column (see Encryptor - Support - Glossary).
• When encrypting or decrypting, the key is written first.
• When encrypting plaintext, the plaintext is written above the ciphertext1.
• When decrypting ciphertext, the ciphertext is written above the plaintext2.

One of the design goals of Encryptor was: Conforming passwords and other authentication tokens generated using Encryptor will be reproducible using pencil-and-paper methods (see Encryptor - About - What makes Encryptor different from other password generators or managers?).

Although the algorithms used to encrypt plaintext are well-known, the implementation for each cipher type is an extension of a more conventional implementation. For example:

• Most pencil-and-paper methods make no distinction between upper and lower case characters3. Either upper case or lower case characters are all that is necessary to clearly convey meaning, and construction of the tabula, if in use, is much simpler when the number of characters in the plaintext alphabet is a minimum, typically 24 or 26. However, it is to our advantage to use upper and lower case characters so that the potential search space is as large as the web service provider allows.
• Most pencil-and-paper methods make no use of special characters. Again, it is to our advantage to use special characters so that the potential search space is as large as the web service provider allows.
• Encryptor allows the user to enter any arbitrary parsable token for the keyword, key, and plaintext, but only valid characters can be used to generate ciphertext. Invalid characters, i.e., characters which are not in the plaintext alphabet, in the keyword, key, or plaintext must be removed.

  Generally, in a more conventional implementation this was not a problem because the user of the pencil-and-paper method was trained in its use and understood that only the characters of the plaintext alphabet were valid. However, it is to our advantage that the potential search space is as large as the web service provider allows. Rather than require the user to carefully select parsable tokens containing only valid characters, Encryptor generates the intermediate variables unique, valid keyword, valid key, and valid plaintext (see Encryptor - About - Intermediate variables) by removing the invalid characters from the corresponding parsable token entered by the user.

To encrypt plaintext using pencil-and-paper methods to reproduce the ciphertext Encryptor generates:

1. Generate the plaintext alphabet.

   The plaintext alphabet characteristics were established by Apple (see Encryptor - Tutorial (T02) - Generating a conforming password). Apple limits the plaintext alphabet to the the 7-bit characters in the ISO-8859-1 character set, and requires conforming passwords to contain upper and lower case characters and decimal digits, but no special characters. The plaintext alphabet resulting from these requirements contains the following 62 characters:

   0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

2. Generate the unique, valid keyword.

   To generate the ciphertext alphabet, we must first determine the unique, valid keyword (see Encryptor - About - Intermediate variables). When the user enters a keyword, Encryptor generates the unique, valid keyword and displays it in the text box to the right of field "Keyword".

   The unique, valid keyword is generated by first extracting valid characters, then unique characters, from parsable token "keyword", in the order in which they occur in parsable token "keyword".

   Based on the personal encryption algorithm in use in Tutorial T02, we entered the keyword "And Abram was fourscore and six years old, when Hagar bare Ishmael to Abram." in field "Keyword". Encryptor generated the unique, valid keyword:

   AndbramwsfouceixylhHgIt

3. Generate the ciphertext alphabet.

   The ciphertext alphabet is generated by appending all characters of the plaintext alphabet not used by the unique, valid keyword to the unique, valid keyword in the order in which they occur in the plaintext alphabet (see Encryptor - About - Intermediate variables).

   The ciphertext alphabet contains the following 62 characters:

   AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

4. Generate the tabula.

   The tabula is generated from the ciphertext alphabet. The first row of the tabula is identical to the ciphertext alphabet. Each succeeding row of the tabula is shifted one character to the left from the preceding row.

   The tabula contains 62 rows:

   AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz
   ndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzA
   dbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAn
   bramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAnd
   ramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndb
   amwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbr
   mwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbra
   wsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbram
   sfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramw
   fouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramws
   ouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsf
   uceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfo
   ceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfou
   eixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouc
   ixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouce
   xylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfoucei
   ylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceix
   lhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixy
   hHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixyl
   HgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylh
   gIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhH
   It0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHg
   t0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgI
   0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt
   123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0
   23456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01
   3456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012
   456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123
   56789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234
   6789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345
   789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456
   89BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234567
   9BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345678
   BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789
   CDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789B
   DEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BC
   EFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCD
   FGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDE
   GJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEF
   JKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFG
   KLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJ
   LMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJK
   MNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKL
   NOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLM
   OPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMN
   PQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNO
   QRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOP
   RSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQ
   STUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQR
   TUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRS
   UVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRST
   VWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTU
   WXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUV
   XYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVW
   YZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWX
   ZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXY
   jkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZ
   kpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZj
   pqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjk
   qvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkp
   vzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpq
   zAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqv

   It may be helpful to Print (⌘P) the tabula for the encryptor created for Tutorial T02 before continuing.

5. Generate the valid key.

   To generate the ciphertext, we must first determine the valid key (see Encryptor - About - Intermediate variables). When the user enters a key, Encryptor generates the valid key and displays it in the text box to the right of field "Key".

   The valid key is generated by extracting valid (but not necessarily unique) characters from parsable token "key", in the order in which they occur in parsable token "key".

   Based on the personal encryption algorithm in use in Tutorial T02, we entered the key "Developer" in field "Key". Encryptor generated the valid key:

   Developer

   All characters are valid.

6. Generate the valid plaintext.

   To generate the ciphertext, we must first determine the valid plaintext (see Encryptor - About - Intermediate variables). When the user enters the plaintext, Encryptor generates the valid plaintext and displays it in the text box to the right of field "Plaintext".

   The valid plaintext is generated by extracting valid (but not necessarily unique) characters from parsable token "plaintext", in the order in which they occur in parsable token "plaintext".

   Because the information stored by Encryptor alone cannot be used to re-create the ciphertext, we entered the arbitrary plaintext "password" in field "Plaintext". Encryptor generated the valid plaintext:

   password

   All characters are valid.

7. Generate the ciphertext.

   We now have all the information we need to encrypt the plaintext: the cipher type, plaintext alphabet, tabula, valid key, and valid plaintext.

   The cipher type determines how Encryptor encrypts plaintext using the valid key (see Encryptor - About - Intermediate variables for a detailed discussion of Encryptor's behavior for all cipher types).

   The cipher type selected for Tutorial T02 is "Vigenère". Because the length of the valid key is greater than or equal to the length of the valid plaintext4, the valid key is used to encrypt the valid plaintext using the tabula. Write the valid key above the valid plaintext, as follows:

   Developer
   password
   

   Encryptor encrypts each character of the valid plaintext using the row of the tabula corresponding to the key column character of the valid key, and so pairs of characters are used. For example, Encryptor encrypts the valid plaintext character "p" using the row of the tabula corresponding to key column character "D", the valid plaintext character "a" using the row of the tabula corresponding to key column character "e", and so on.

   Each character of the ciphertext is therefore determined by locating the character at the intersection of column (for the valid plaintext) and row (for the valid key). The column is the column of the plaintext alphabet corresponding to the character of the valid plaintext in each pair. The row is the row of the tabula corresponding to the character of the valid key in each pair. The ciphertext character is determined by moving down the column and across the row. The ciphertext character is the character at their intersection. For example:

   1. Determining the first character of the ciphertext.

      The column is the column of the plaintext alphabet corresponding to the first character of the valid plaintext ("password"): "p".

      The row is the row of the tabula corresponding to the first character of the valid key ("Developer"): "D".

      The ciphertext character is determined by moving down the column and across the row:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz
      ndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzA
      dbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAn
      bramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAnd
      ramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndb
      amwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbr
      mwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbra
      wsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbram
      sfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramw
      fouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramws
      ouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsf
      uceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfo
      ceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfou
      eixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouc
      ixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouce
      xylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfoucei
      ylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceix
      lhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixy
      hHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixyl
      HgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylh
      gIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhH
      It0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHg
      t0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgI
      0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt
      123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0
      23456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01
      3456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012
      456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123
      56789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234
      6789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345
      789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456
      89BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234567
      9BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345678
      BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789
      CDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789B
      DEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BC
      EFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCD
      FGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDE
      GJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEF
      JKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFG
      KLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJ
      LMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJK
      MNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKL
      NOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLM
      OPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMN
      PQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNO
      QRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOP
      RSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQ
      STUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQR
      TUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRS
      UVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRST
      VWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTU
      WXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUV
      XYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVW
      YZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWX
      ZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXY
      jkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZ
      kpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZj
      pqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjk
      qvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkp
      vzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpq
      zAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqv

      The first character of the ciphertext is "1":

      Developer
      password
      1

   2. Determining the second character of the ciphertext.

      The column is the column of the plaintext alphabet corresponding to the second character of the valid plaintext ("password"): "a".

      The row is the row of the tabula corresponding to the second character of the valid key ("Developer"): "e".

      The ciphertext character is determined by moving down the column and across the row:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz
      ndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzA
      dbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAn
      bramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAnd
      ramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndb
      amwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbr
      mwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbra
      wsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbram
      sfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramw
      fouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramws
      ouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsf
      uceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfo
      ceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfou
      eixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouc
      ixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouce
      xylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfoucei
      ylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceix
      lhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixy
      hHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixyl
      HgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylh
      gIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhH
      It0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHg
      t0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgI
      0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt
      123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0
      23456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01
      3456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012
      456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123
      56789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234
      6789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345
      789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456
      89BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234567
      9BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345678
      BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789
      CDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789B
      DEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BC
      EFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCD
      FGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDE
      GJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEF
      JKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFG
      KLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJ
      LMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJK
      MNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKL
      NOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLM
      OPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMN
      PQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNO
      QRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOP
      RSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQ
      STUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQR
      TUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRS
      UVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRST
      VWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTU
      WXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUV
      XYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVW
      YZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWX
      ZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXY
      jkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZ
      kpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZj
      pqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjk
      qvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkp
      vzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpq
      zAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqv

      The second character of the ciphertext is "T":

      Developer
      password
      1T

   3. Determining the third character of the ciphertext.

      The column is the column of the plaintext alphabet corresponding to the third character of the valid plaintext ("password"): "s".

      The row is the row of the tabula corresponding to the third character of the valid key ("Developer"): "v".

      The ciphertext character is determined by moving down the column and across the row:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz
      ndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzA
      dbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAn
      bramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAnd
      ramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndb
      amwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbr
      mwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbra
      wsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbram
      sfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramw
      fouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramws
      ouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsf
      uceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfo
      ceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfou
      eixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouc
      ixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouce
      xylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfoucei
      ylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceix
      lhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixy
      hHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixyl
      HgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylh
      gIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhH
      It0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHg
      t0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgI
      0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt
      123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0
      23456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01
      3456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012
      456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123
      56789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234
      6789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345
      789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456
      89BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234567
      9BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345678
      BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789
      CDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789B
      DEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BC
      EFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCD
      FGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDE
      GJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEF
      JKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFG
      KLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJ
      LMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJK
      MNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKL
      NOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLM
      OPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMN
      PQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNO
      QRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOP
      RSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQ
      STUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQR
      TUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRS
      UVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRST
      VWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTU
      WXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUV
      XYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVW
      YZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWX
      ZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXY
      jkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZ
      kpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZj
      pqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjk
      qvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkp
      vzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpq
      zAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqv

      The third character of the ciphertext is "W":

      Developer
      password
      1TW

   4. Determining the fourth character of the ciphertext.

      The column is the column of the plaintext alphabet corresponding to the fourth character of the valid plaintext ("password"): "s".

      The row is the row of the tabula corresponding to the fourth character of the valid key ("Developer"): "e".

      The ciphertext character is determined by moving down the column and across the row:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz
      ndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzA
      dbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAn
      bramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAnd
      ramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndb
      amwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbr
      mwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbra
      wsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbram
      sfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramw
      fouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramws
      ouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsf
      uceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfo
      ceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfou
      eixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouc
      ixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouce
      xylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfoucei
      ylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceix
      lhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixy
      hHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixyl
      HgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylh
      gIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhH
      It0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHg
      t0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgI
      0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt
      123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0
      23456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01
      3456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012
      456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123
      56789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234
      6789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345
      789BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456
      89BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt01234567
      9BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt012345678
      BCDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789
      CDEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789B
      DEFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BC
      EFGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCD
      FGJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDE
      GJKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEF
      JKLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFG
      KLMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJ
      LMNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJK
      MNOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKL
      NOPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLM
      OPQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMN
      PQRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNO
      QRSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOP
      RSTUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQ
      STUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQR
      TUVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRS
      UVWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRST
      VWXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTU
      WXYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUV
      XYZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVW
      YZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWX
      ZjkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXY
      jkpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZ
      kpqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZj
      pqvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjk
      qvzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkp
      vzAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpq
      zAndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqv

      The fourth character of the ciphertext is "a":

      Developer
      password
      1TWa

   This procedure continues until each character of the valid plaintext is encrypted. The resulting ciphertext is:

   Developer
   password
   1TWaevTW

Endnotes.

This tutorial is based on tutorial: Encryptor - Tutorial (T02) - Generating a conforming password (herein "Tutorial T02"), and uses the same plaintext alphabet characteristics and parsable tokens. The cipher type selected for Tutorial T02 is "Vigenère". However, for the purposes of this example, a cipher type of "Keyword substitution" is asserted.

The purpose of this tutorial is to demonstrate how to encrypt plaintext using pencil-and-paper methods to reproduce the ciphertext Encryptor generates. This tutorial is specific to cipher type "Keyword substitution".

One of the design goals of Encryptor was: Conforming passwords or other authentication tokens generated using Encryptor will be indistinguishable from random text (see Encryptor - About - What makes Encryptor different from other password generators or managers?). Keyword substitution is the weakest pencil-and-paper method implemented by Encryptor. Encryptor implements keyword substitution because:

• It is the easiest to reconstruct.
• The plaintext alphabet may contain arbitrary upper and lower case characters, decimal digits, and special characters.
• If a sufficiently complex keyword is used, for example, containing a mix of upper and lower case characters, decimal digits, and special characters, the ciphertext alphabet differs significantly from the plaintext alphabet.
• If the plaintext is also sufficiently complex, the ciphertext is indistinguishable from random text.

As a result, careful selection of the keyword and plaintext are important when cipher type "Keyword substitution" is selected. However, because the plaintext alphabet characteristics are established by the web service provider, users should be aware that selecting cipher type "Keyword substitution" may not generate ciphertext which is indistinguishable from random text.

Also, if an insufficiently complex keyword is used, cipher type "Keyword substitution" is less likely to generate a conforming password because the ciphertext alphabet does not differ significantly from the plaintext alphabet. Append or prepend a token known only to you to the ciphertext generated by Encryptor to generate a conforming password (see Encryptor - Support - Tips and tricks).

Before discussing how Encryptor generates ciphertext, it is first necessary to establish some conventions which are basic to cryptography in general. These conventions will be used throughout this tutorial:

• When encrypting plaintext, the plaintext is written above the ciphertext.
• When decrypting ciphertext, the ciphertext is written above the plaintext.

One of the design goals of Encryptor was: Conforming passwords and other authentication tokens generated using Encryptor will be reproducible using pencil-and-paper methods (see Encryptor - About - What makes Encryptor different from other password generators or managers?).

Although the algorithms used to encrypt plaintext are well-known, the implementation for each cipher type is an extension of a more conventional implementation. For example:

• Most pencil-and-paper methods make no distinction between upper and lower case characters1. Either upper case or lower case characters are all that is necessary to clearly convey meaning, and construction of the ciphertext alphabet is much simpler when the number of characters in the plaintext alphabet is a minimum, typically 24 or 26. However, it is to our advantage to use upper and lower case characters so that the potential search space is as large as the web service provider allows.
• Most pencil-and-paper methods make no use of special characters. Again, it is to our advantage to use special characters so that the potential search space is as large as the web service provider allows.
• Encryptor allows the user to enter any arbitrary parsable token for the keyword, key, and plaintext, but only valid characters can be used to generate ciphertext. Invalid characters, i.e., characters which are not in the plaintext alphabet, in the keyword, key, or plaintext must be removed.

  Generally, in a more conventional implementation this was not a problem because the user of the pencil-and-paper method was trained in its use and understood that only the characters of the plaintext alphabet were valid. However, it is to our advantage that the potential search space is as large as the web service provider allows. Rather than require the user to carefully select parsable tokens containing only valid characters, Encryptor generates the intermediate variables unique, valid keyword, valid key, and valid plaintext (see Encryptor - About - Intermediate variables) by removing the invalid characters from the corresponding parsable token entered by the user.

To encrypt plaintext using pencil-and-paper methods to reproduce the ciphertext Encryptor generates:

1. Generate the plaintext alphabet.

   The plaintext alphabet characteristics were established by Apple (see Encryptor - Tutorial (T02) - Generating a conforming password). Apple limits the plaintext alphabet to the the 7-bit characters in the ISO-8859-1 character set, and requires conforming passwords to contain upper and lower case characters and decimal digits, but no special characters. The plaintext alphabet resulting from these requirements contains the following 62 characters:

   0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

2. Generate the unique, valid keyword.

   To generate the ciphertext alphabet, we must first determine the unique, valid keyword (see Encryptor - About - Intermediate variables). When the user enters a keyword, Encryptor generates the unique, valid keyword and displays it in the text box to the right of field "Keyword".

   The unique, valid keyword is generated by first extracting valid characters, then unique characters, from parsable token "keyword", in the order in which they occur in parsable token "keyword".

   Based on the personal encryption algorithm in use in Tutorial T02, we entered the keyword "And Abram was fourscore and six years old, when Hagar bare Ishmael to Abram." in field "Keyword". Encryptor generated the unique, valid keyword:

   AndbramwsfouceixylhHgIt

3. Generate the ciphertext alphabet.

   The ciphertext alphabet is generated by appending all characters of the plaintext alphabet not used by the unique, valid keyword to the unique, valid keyword in the order in which they occur in the plaintext alphabet (see Encryptor - About - Intermediate variables).

   The ciphertext alphabet contains the following 62 characters:

   AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

4. Generate the valid plaintext.

   To generate the ciphertext, we must first determine the valid plaintext (see Encryptor - About - Intermediate variables). When the user enters the plaintext, Encryptor generates the valid plaintext and displays it in the text box to the right of field "Plaintext".

   The valid plaintext is generated by extracting valid (but not necessarily unique) characters from parsable token "plaintext", in the order in which they occur in parsable token "plaintext".

   Because the information stored by Encryptor alone cannot be used to re-create the ciphertext, we entered the arbitrary plaintext "password" in field "Plaintext". Encryptor generated the valid plaintext:

   password

   All characters are valid.

5. Generate the ciphertext.

   We now have all the information we need to encrypt the plaintext: the cipher type, plaintext alphabet, ciphertext alphabet, and valid plaintext.

   The cipher type determines how Encryptor encrypts plaintext using the valid key. See Encryptor - About - Intermediate variables for a detailed discussion of Encryptor's behavior for all cipher types.

   The cipher type selected for Tutorial T02 is "Vigenère". However, for the purposes of this example, a cipher type of "Keyword substitution" is asserted. Write the valid plaintext, as follows:

   password
   

   Encryptor encrypts each character of the valid plaintext using the corresponding character of the ciphertext alphabet. For example:

   1. Determining the first character of the ciphertext.

      The plaintext character is the character of the plaintext alphabet corresponding to the first character of the valid plaintext ("password"): "p".

      The ciphertext character is the corresponding character of the ciphertext alphabet:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

      The first character of the ciphertext is "V":

      password
      V

   2. Determining the second character of the ciphertext.

      The plaintext character is the character of the plaintext alphabet corresponding to the second character of the valid plaintext ("password"): "a".

      The ciphertext character is the corresponding character of the ciphertext alphabet:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

      The second character of the ciphertext is "E":

      password
      VE

   3. Determining the third character of the ciphertext.

      The plaintext character is the character of the plaintext alphabet corresponding to the third character of the valid plaintext ("password"): "s".

      The ciphertext character is the corresponding character of the ciphertext alphabet:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

      The third character of the ciphertext is "Y":

      password
      VEY

   4. Determining the fourth character of the ciphertext.

      The plaintext character is the character of the plaintext alphabet corresponding to the fourth character of the valid plaintext ("password"): "s".

      The ciphertext character is the corresponding character of the ciphertext alphabet:

      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
      AndbramwsfouceixylhHgIt0123456789BCDEFGJKLMNOPQRSTUVWXYZjkpqvz

      The first character of the ciphertext is "Y":

      password
      VEYY

   This procedure continues until each character of the valid plaintext is encrypted. The resulting ciphertext is:

   password
   VEYYpUXJ

   This is not a conforming password. However, append or prepend a token known only to you to the ciphertext generated by Encryptor to generate a conforming password (see Encryptor - Support - Tips and tricks):

   d0GVEYYpUXJ

Endnotes.

1. Initial attempts to validate the utility were unsuccessful.

   For reproducibility by an independent third party, all validation was performed using desktop office software to generate pseudorandom 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.

2. The validation protocol was revised.
   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.
3. Conclusion

   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.

Because of Allen's focus on test-driven development, the testing of Encryptor has focused on formal validation using randomly-selected parsable tokens and manual testing of features such as Print, Export, and Save, Save As... and Quit.

This document describes validation of Encryptor's implementation of cipher type. The cipher type determines how Encryptor encrypts plaintext using the valid key (see Encryptor - About - Intermediate variables). This document does not describe formal validation of Encryptor using randomly-selected parsable tokens (see Encryptor - Validation - Standard test cases).

The standard test cases described in this document are available as an XML document for download (see Encryptor - Downloads - Cipher type implementation - Standard test cases). Import (⌘I) that document into Encryptor to validate Encryptor's cipher type implementation in accordance with this document.

It may be helpful to Print (⌘P) the tabula from the downloaded document before continuing. Because we are encrypting plaintext, the key-plaintext-ciphertext convention is used throughout this document (see Encryptor - Tutorial (T07) - How Encryptor encrypts plaintext).

1. For all test cases:
   • The plaintext alphabet contains only the lower case characters of the 7-bit ISO-8859-1 character set:

     abcdefghijklmnopqrstuvwxyz

   • Do not enter a keyword.
   • The ciphertext alphabet contains only the lower case characters of the 7-bit ISO-8859-1 character set1:

     abcdefghijklmnopqrstuvwxyz

   • The tabula contains 26 rows:

     abcdefghijklmnopqrstuvwxyz
     bcdefghijklmnopqrstuvwxyza
     cdefghijklmnopqrstuvwxyzab
     defghijklmnopqrstuvwxyzabc
     efghijklmnopqrstuvwxyzabcd
     fghijklmnopqrstuvwxyzabcde
     ghijklmnopqrstuvwxyzabcdef
     hijklmnopqrstuvwxyzabcdefg
     ijklmnopqrstuvwxyzabcdefgh
     jklmnopqrstuvwxyzabcdefghi
     klmnopqrstuvwxyzabcdefghij
     lmnopqrstuvwxyzabcdefghijk
     mnopqrstuvwxyzabcdefghijkl
     nopqrstuvwxyzabcdefghijklm
     opqrstuvwxyzabcdefghijklmn
     pqrstuvwxyzabcdefghijklmno
     qrstuvwxyzabcdefghijklmnop
     rstuvwxyzabcdefghijklmnopq
     stuvwxyzabcdefghijklmnopqr
     tuvwxyzabcdefghijklmnopqrs
     uvwxyzabcdefghijklmnopqrst
     vwxyzabcdefghijklmnopqrstu
     wxyzabcdefghijklmnopqrstuv
     xyzabcdefghijklmnopqrstuvw
     yzabcdefghijklmnopqrstuvwx
     zabcdefghijklmnopqrstuvwxy

   • Enter the plaintext "password". The valid plaintext is "password".
2. Test case "01".

   The length of the valid key is zero.

   • Verify the following input:

     Cipher type:
     

     Vigenère
     

     Key (valid key):
     

     -none-
     

   • Verify no ciphertext is generated.
   • Verify Encryptor reports:

     WARNING! For a Vigenère cipher, a key is required.

3. Test case "02".

   The length of the valid key is less than the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Vigenère
     

     Key (valid key):
     

     key (key)
     

   • Verify the following ciphertext is generated:

     keykeykey
     password
     zeqcambh

4. Test case "03".

   The length of the valid key is greater than or equal to the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Vigenère
     

     Key (valid key):
     

     validkey (validkey)
     

   • Verify the following ciphertext is generated:

     validkey
     password
     kadazyvb

   • Verify Encryptor reports:

     The length of the valid key is greater than or equal to the length of the valid plaintext.  This is effectively a running key cipher.

5. Test case "04".

   The length of the valid key is zero.

   • Verify the following input:

     Cipher type:
     

     Autokey
     

     Key (valid key):
     

     -none-
     

   • Verify the following ciphertext is generated:

     password
     password
     eakkscig

6. Test case "05".

   The length of the valid key is less than the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Autokey
     

     Key (valid key):
     

     key (key)
     

   • Verify the following ciphertext is generated:

     keypassword
     password
     zeqhwgjz

7. Test case "06".

   The length of the valid key is greater than or equal to the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Autokey
     

     Key (valid key):
     

     validkey (validkey)
     

   • Verify the following ciphertext is generated:

     validkey
     password
     kadazyvb

   • Verify Encryptor reports:

     The length of the valid key is greater than or equal to the length of the valid plaintext.  This is effectively a running key cipher.

8. Test case "07".

   The length of the valid key is less than the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Running key
     

     Key (valid key):
     

     key (key)
     

   • Verify no ciphertext is generated.
   • Verify Encryptor reports:

     WARNING! For a running key cipher, a valid key is required, and the length of the valid key must be greater than the length of the valid plaintext.
     
     The length of the valid key ("key") is 3.
     
     The length of the valid plaintext ("password") is 8.

9. Test case "08".

   The length of the valid key is greater than or equal to the length of the valid plaintext.

   • Verify the following input:

     Cipher type:
     

     Running key
     

     Key (valid key):
     

     validkey (validkey)
     

   • Verify the following ciphertext is generated:

     validkey
     password
     kadazyvb

Endnotes.

This document describes validation of Encryptor's print behavior, in general, and describes a method by which users of Encryptor may quickly and easily validate a tabula printed across multiple vertically or horizontally-tiled pages. This document does not describe formal validation of Encryptor using randomly-selected parsable tokens (see Encryptor - Validation - Standard test cases).

Encryptor prints an outer border and inner offset border on each page as a visual guide for alignment when printing multiple vertically- or horizontally-tiled pages, and to serve as crop marks if the user wants to join printed pages to each other.

• The outer border.

  The outer border represents the printable area of the page. The width and height of the outer border are determined by the size of the printable area of the page, and are therefore the same on each printed page. Changing the paper size or printing to a different printer affects the size of the printable area of the page, and therefore the width and height of the outer border.

• The inner offset border.

  The inner offset border represents the portion of the printable area of the page in which the maximum number of columns or rows may be printed. The width and height of the inner offset border are determined by the maximum number of columns or rows which may be printed per page using the default line height of 1.5 and default font point size of 10 points, and are therefore the same on each printed page. Changing the paper size or printing to a different printer affects the size of the printable area of the page, and the maximum number of columns or rows which may be printed.

  The position of the inner offset border is determined by the page's position across multiple vertically- or horizontally-tiled pages as either a top, middle, or bottom page, and either left, middle, or right page. With the exception of the middle pages in either dimension, the inner offset border is printed so that it is flush with the joining edge(s) of the paper. Because both the top and bottom edges of vertically-tiled middle pages are joining edges, only the left or right edges are significant, and the inner offset border is printed so that it is flush with either the left or right edge of the paper. Likewise, because both the left and right edges of horizontally-tiled middle pages are joining edges, only the top or bottom edges are significant, and the inner offset border is printed so that it is flush with either the top or bottom edge of the paper.

The standard test cases described in this document are available as an XML document for download (see Encryptor - Downloads - Printing - Standard test cases). Import (⌘I) that document into Encryptor to validate Encryptor's Print implementation in accordance with this document.

However, validation of Encryptor's print behavior is based on 38 columns per page by 48 rows calculated using the default line height of 1.5 and default font point size of 10 points, and the printable area of letter size paper when printing to a Samsung ML-1450. Changing the paper size or printing to a different printer affects the size of the printable area of the page, and the maximum number of columns or rows which may be printed.

When the phrase "Verify Encryptor centers..." (or a similar phrase) is used throughout this document: measurements are taken from the outer border to the tabula on all four sides. Corresponding measurements in one dimension (i.e., left outer border-tabula and tabula-right outer border or top outer border-tabula and tabula-bottom outer border) which are within 1/32 inch of each other are considered identical and the tabula considered centered in that dimension.

1. Test case "01p".
   • Verify the "Print..." command is disabled.
2. Test case "02p".
   • Verify Encryptor prints one (1) page.
   • Verify Encryptor prints both the plaintext and ciphertext alphabets ("alphabets").
   • Verify Encryptor horizontally centers the alphabets. Encryptor does not vertically center the alphabets when printing an encryptor with a cipher type of "Keyword substitution".
   • Verify Encryptor divides the alphabets into rows of the same length. If more than one row is required, the last row may be shorter than the preceding row(s). The maximum difference between the lengths of the last row and the preceding row(s) will be equal to one less than the total number of rows.
   • Verify Encryptor adds white space equal in height to the height of the alphabets between successive rows.
3. For test cases "03pe" through "10po":
   • Verify Encryptor prints the plaintext alphabet and tabula recta ("tabula") by counting the number of columns and rows:
     • Verify the number of columns is equal to the number of characters in the alphabets.
     • Verify the number of rows is equal to one greater than the number of columns, i.e., the number of characters in the alphabets.
   • Verify a line drawn diagonally from the bottom-left corner of the tabula to the upper-right corner intersects the same character of the ciphertext alphabet in every column and row, and that the character is the last character of the ciphertext alphabet.
   1. Test cases "03pe" and "03po".
      • Verify Encryptor prints one (1) page.
      • Verify Encryptor vertically and horizontally centers the plaintext alphabet and tabula.
   2. Test case "04pe".
      • Verify Encryptor prints two (2) pages.
      • When printing in portrait mode, verify Encryptor vertically and horizontally centers the plaintext alphabet and tabula across the tiled pages. Because the number of tiled pages in the long dimension (vertically-tiled pages based on "Page Setup... > Orientation") is one (1), and the number of characters in the alphabets is even, Encryptor vertically and horizontally centers the plaintext alphabet and tabula.
      • When printing in landscape mode, verify Encryptor horizontally centers the plaintext alphabet and tabula across the tiled pages. Because the number of tiled pages in the long dimension (horizontally-tiled pages based on "Page Setup... > Orientation") is one (1), and the number of characters in the alphabets is even and one additional row is required to print the plaintext alphabet, the number of rows is odd and cannot be evenly divided across two vertically-tiled pages. Twenty-one (21) rows are printed on the first page. Twenty-two (22) rows are printed on the second page.
   3. Test case "04po".
      • Verify Encryptor prints two (2) pages.
      • When printing in portrait mode, verify Encryptor vertically centers the plaintext alphabet and tabula across the tiled pages. Because the number of tiled pages in the long dimension (vertically-tiled pages based on "Page Setup... > Orientation") is one (1), and the number of characters in the alphabets is odd, the number of columns is odd and cannot be evenly divided across two horizontally-tiled pages. Twenty-one (21) columns are printed on the first page. Twenty-two (22) columns are printed on the second page.
      • When printing in landscape mode, verify Encryptor vertically and horizontally centers the plaintext alphabet and tabula across the tiled pages. Because the number of tiled pages in the long dimension (horizontally-tiled pages based on "Page Setup... > Orientation") is one (1), and the number of characters in the alphabets is odd and one additional row is required to print the plaintext alphabet, the number of rows is even and can be evenly divided across two vertically-tiled pages. Twenty-two (22) rows are printed on each page.
   4. Test case "05pe".
      • Verify Encryptor prints four (4) pages.
      • When printing in portrait or landscape mode, verify Encryptor horizontally centers the plaintext alphabet and tabula across the tiled pages. Because the number of characters in the alphabets is even, and one additional row is required to print the plaintext alphabet, the number of rows is odd and cannot be evenly divided across the vertically-tiled pages. Thirty-one (31) rows are printed on each top page. Thirty-two (32) rows are printed on each bottom page.
   5. Test case "05po".
      • When printing in portrait or landscape mode, verify Encryptor vertically centers the plaintext alphabet and tabula across the tiled pages. Because the number of characters in the alphabets is odd, and one additional row is required to print the plaintext alphabet, the number of rows is even and can be evenly divided across the vertically-tiled pages. Thirty-two (32) rows are printed on each page.
   6. Test cases "06pe" through "10po".

      To make the best possible use of the standard test cases described in this article, test cases "02p" through "05po" were printed to PDF by Encryptor in both portrait and landscape mode, then to a Samsung ML-1450 as transparencies by Preview. These test cases allow me to confirm top, middle, and bottom, and left, middle, and right pages are printed correctly for cipher types other than "None". Printed output from Encryptor is validated using these transparencies as an overlay when changes which potentially affect the printing implementation are made.

      Test cases "06pe" through "10po" were not printed to transparencies. These test cases were verified using the method described below:

      I first draw a box on quad-ruled paper for each tiled page, in the position in which each page is printed. For example:

      By default the number of characters in the alphabets is 95: 26 uppercase letters, 26 lowercase letters, ten (10) decimal digits, and 33 special characters. Based on 38 columns per page by 48 rows calculated using the default line height of 1.5 and default font point size of 10 points, and the printable area of letter size paper when printing to a Samsung ML-1450 in portrait mode, Encryptor prints two vertically-tiled pages and three horizontally-tiled pages, for a total of six pages.

      I therefore draw six boxes, two rows of three boxes each.

      In the upper left-hand corner of each box, I print the character in the upper left-hand corner of the tabula for that page, in the upper right-hand corner of each box, I print the character in the upper right-hand corner of the tabula for that page, and so on, until the characters in the corners of each page are recorded in the corners of the corresponding box for that page. Note that because Encryptor prints the plaintext alphabet above the tabula, the first row of the tabula is the row underneath the plaintext alphabet, and not the first row printed.

      I match the characters on the right side of each box with the characters on the left side of the next box in that row, i.e., the box to the right. The character on the left side of the box to the right should be the next character in the ciphertext alphabet. Due to the symmetric nature of the tabula, the right side of the last box in each row will "wrap around" and match those on the left side of the first box in each row.

      I match the characters on the bottom side of each box with the characters on the top side of the next box in that column, i.e., the box below. The character on the top side of the box below should be the next character in the ciphertext alphabet. Due to the symmetric nature of the tabula, the bottom side of the last box in each column will "wrap around" and match those on the top side of the first box in each column.

      I match the characters in the upper right-hand corner of each box with the character in the lower-left corner of the box one row above and to the right. The character in the lower-left corner of the box one row above and to the right should be the next character in the ciphertext alphabet. Due to the symmetric nature of the tabula, the character in the upper-right corner of the first box in each column will "wrap around" on the top side and match the character in the lower-left corner of the last box in the column to the right and the character in the upper-right corner of the last box in each row will wrap around on the right side and match the character in the lower-left corner of the first box one row above.

      If the characters on the right side match those on the left, the characters on the bottom side match those on the top, and the characters in the upper-right corner match those in the lower-left, the tabula is complete.