rotor alternative?

[Paul Rubin]

"Dave Brueck" <dave at pythonapocrypha.com> writes:
> 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).

But the internal state of the rotor system has fixed size, no matter
how long the key is.  In the case of the Python rotor module, that
size is 10 bytes, though of course there are much better attacks than
brute force search.

> 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).

In that case we can just use the random cd as an additive one-time pad
and have no need for rotor algorithms.  Note that we won't get any
authentication either way.

> 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, 

But in fact the likelihood of such an attack is much lower than the
likelihood of the CD itself getting intercepted by an attacker.  Really,
this stuff gets rehashed on sci.crypt almost every week, it gets boring
after a while.

> 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.

There are much better algorithms than rotor even for tiny cpu's.
Skipjack, for example, needs only about 3 bytes of scratch ram on an
8-bit cpu while any reasonable rotor cipher needs far more than that.

> Also, with rotor errors in the key cause only localized damage in
> the data stream, 

Several of the standard block cipher chaining modes have the same property.

> 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.

But that's silly, you have to assume that your attacker knows what
methods and key sources you're using (Kerchoff principle).  If you
can't securely exchange a shared secret key beforehand, the solution
is to use a public-key key agreement algorithm with locally generated
random data at each end, not crazy crap like digitizing a CNN feed.

> (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. :) )

But it really is totally useless nowadays, unless you want an insecure
system.