rotor alternative?

[Dave Brueck]

Peter wrote:
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms?  Can anyone describe it perhaps
> in comparison with DES/3DES using a kind of "equivalent key size" estimate?

Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis, its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).

For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing
power that can crack a single intercepted message using a brute force approach
(because cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several times the
length of the key).

Obviously you could use the face-to-face meeting to exchange a CD of AES keys
to use, but each intercepted message would, in theory, be open to a brute force
attack, unless every AES-bitKeyLength/8 bytes of the message were encrypted
with a new key from the CD, but it would be far more expensive
computationally - using "modern" encryption algorithms is just a trade off
because for many appications CPU cycles are an abundant resource. But there do
exist situations where you are CPU constrained, so it may be a good tradeoff
for e.g. an embedded device with limited CPU to use a rotor-like algorithm and
its own ROM as the key.

Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.

(I'm not suggesting that we should be using rotor everywhere, just pointing
that it has some cool properties and isn't totally useless nowadays. :) )

-Dave