One of the most important ideas embodied in CA-1.0 is the use of inverse iteration of irreversible cellular automata for encryption coupled with forward iteration of the same rules for decryption. States under a reversible rule always have one and only one preimage. States under an irreversible rule, on the other hand, may have either many or no preimages. If states can have no preimages under a given cellular automaton, then the cellular automaton cannot always be inverse iterated. Such rules are to be avoided in applications to cryptography. If states always have more than one preimage, then any one of them can be used to inverse iterate the cellular automaton. Cryptography presents the challenge of finding irreversible rules under which all blocks have preimages, and such that the preimages can be constructed rapidly.
In CA-1.0 the irreversible rules used have a property known as the toggle property. Cellular automata may be either left-toggle or right-toggle or both. A cellular automaton is a left-toggle cellular automaton if equation (1) holds and:
Similarly, a cellular automaton is a right-toggle cellular automaton if equation (1) holds and:
These equations mean that rules are toggle rules if changing the
value of the (either left or right) extreme site always changes
the result of the function 
. Changing the value of the extreme
site thus toggles the value of the central site at the next time
step. All blocks have the
same non-zero number of preimages under a toggle cellular automaton.
Moreover, a preimage for any block can be rapidly constructed.
The way inverse iteration of toggle rules is applied in cryptography is explained by using a particular cellular automaton rule as an example. This is the cellular automaton known as rule 30. Its rule table is found in column 2 of table 1. Rule 30 is a left-toggle rule. A preimage for a block can be constructed by 1) choosing the initial right-most bits arbitrarily, and 2) finding successive bits moving rightward, by reference to table 1, and using the two previous bits in the preimage. Table 2 shows how this process can be used to encrypt a block of information using rule 30. In each line of the top half of this table, the right-most two bits are chosen randomly, and then the rest of the line is constructed by reference to table 1. The bottom half of the table shows the cellular automaton applied to the ciphertext to recover the plaintext.
Note that while decryption is parallel in the data, encryption can be performed parallel in the iterations. That is, in decryption there can be one processor for each bit of data whose task is to update the data bit by reference to the rule table. In encryption, however, a bit cannot be updated until bits to its right are updated. Still, if a processor is assigned to each iteration, each processor can begin working as soon as it is charged with its initial, arbitrary, two bits. All the processors can be charged initially at the same time. Each can begin immediately to construct its line of intermediate ciphertext, since the data it needs to do so are available from the processor below it, and so on down the chain until the plaintext is reached. Iteration-parallel encryption is possible not only with rule 30, but with any toggle rule.
Table 1: Lookup tables for iteration of cellular automaton rules 54
(a general rule), 30 (a left-toggle rule) and 149 (a right-toggle rule).
Table 2: This table shows encryption/decryption of a block using
left-toggle rule 30. The plaintext is written at step 0 of encryption,
and step 14 of decryption. The corresponding ciphertext is written at
step 14 of encryption and step 0 of decryption. The input link information
is in the right-most two bits of each line.
A variant of the display format used in table 2 allows the resistance of rule 30 to cryptanalytic attack to be easily studied. In this variant, two plaintexts which differ at only one site are encrypted, and an XOR all pairs of intermediate states taken. One member of the pair is the all-0 plaintext, the other, the all-but-0 plaintext in which one bit has been set to 1. The result of this procedure is shown in table 3. In this table, a difference is represented by a ``#" and no difference by a symbol ``_". Note that the single bit error in the plaintext propagates across the ciphertext, albeit only to the left. When both left- and right-toggle rules are used as in CA-1.0, errors are spread in both directions. Difference patterns for CA-1.0 are discussed in section 5.
Table 4 is similar to table 3, though here the difference is between a pair of decryptions in which a single error has been introduced into one of the ciphertexts. Note that the single error propagates as decryption proceeds. If a sufficient number of decryption steps are used, then the single error may provoke differences across the entire plaintext.
Table: Propagation of a single error introduced into the plaintext.
``_" = site same as with no error ``#"= site differs with error.
Table: Propagation of a single error introduced into the ciphertext.
``_" = site same as with no error ``#"= site differs with error.