vulcan-cryptanalysis

to us that it would have made more sense to either have allowed the user to
enter all 138 bits, or to have made Vulcan use a shorter cryptovariable.
As an aside, we also note that the DVP key loader lacks the ability to
generate a random cryptovariable, requiring the user to enter a CV of their own
creation. This is certain to lead to poorly-chosen values, as our experience is
that many users of cryptographic equipment, when allowed to choose their own
CV, will simply enter an easily guessed sequence such as 1234..., etc.
One might intuitively think that limiting the CV to 71 bits greatly reduces
overall security, given that the Vulcan CV is natively 138 bits; however, since the
Vulcan cipher is effectively linear, the length of the CV is of little consequence.
Solving a system of linear equations in 138 unknowns is scarcely more difficult
than solving a system of linear equations in 71 unknowns (or far fewer, for
that matter). Motorola most likely realized this and made their decision on
cryptovariable length accordingly.
Another possibility regarding the length of the cryptovariable is the influence
of external constraints, such as export restrictions. We know that in the 1990s,
the US government would only allow export of cryptography restricted to 40 or
fewer bits of cryptovariable [4]. We do not know what the restrictions were in
the 1970s, but we can safely assume they were no more permissive than they
were in the 1990s, and were likely less so. Again we are left to guess as to what
the true reasons behind Vulcan’s unusual CV length were.
Our second question is why Vulcan is so weak. Admittedly, cryptography
was much less well understood in the early 1970s than it is today; nonetheless,
anyone with an undergraduate education in mathematics would have known at
that time that Vulcan was seriously weak. It would not surprise us if this was
deliberate.
Inspection of the SC76807 IC layout reveals certain clues as to alternatives
the designers might have had in mind. Specifically, the XOR tree has provisions
to accommodate additional bits from the CV shift register, yet this circuitry is
not hooked up. Also, the ciphertext shift register has a provision for insertion
or extraction of bits approximately half-way through its 21 bits, a feature that
was not used and the purpose of which is not clear to us.
Strictly speaking, Vulcan is nonlinear due to the GF (2) multiplications
present in the XOR tree; however, as we have shown, we can linearize Vulcan
by assuming these GF (2) multiplications simply represent bits that must
be solved for via exhaustive search. Since there are only seven unknowns, this
exhaustive search is trivial. The designers could have made exhaustive search
far less fruitful by including more bits from the CV shift register in the GF (2)
multiplications, but they chose not to do so. We are puzzled by this.
Furthermore, even a simple nonlinear operation in the ciphertext mixing
function would have eliminated the simple attack of linear algebra, but the
designers chose not to do this either. We cannot offer a reasonable explanation
why a simple nonlinearity was not included in order to strengthen Vulcan. Our
suspicion is that Vulcan is deliberately weak, although we have no proof of
this. Nonetheless, we prefer this explanation to the alternative possibility that
the designers were simply incompetent. Now that Vulcan has been thoroughly
26