rotor alternative?

[John J. Lee]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> jjl at pobox.com (John J. Lee) writes:
[...]
> I don't know of any country that controls strong encryption and
> doesn't control weak encryption.  Back before the US export controls
[...]

That's interesting.


> > Second, if you have
> > to have the key around anyway (true for some applications), it really
> > doesn't matter how secure the algorithm is.
> 
> I'm not sure what you're getting at here.  The normal use of
> cryptography is to transmit or store data that can be intercepted by
> an attacker.  Obviously you don't transmit or store the key with the
> data.

Oh, do we have to go around this loop again?

You can if your aim is _obfuscation_: simply to place a minimal
barrier in front of people so they have to do something more than XOR
some data.  Regardless of the facts that breaking rotor encryption
takes little computing poser, and that knowledgeable people can and do
write code-breaking programs for the rest of us to use without needing
to know anything, the act of obtaining such a program is itself a
psychological barrier to decryption: you can't fool yourself about
what you're doing.  Arguably XOR comes appreciably lower down the PITA
scale, since the decryption algorithm is trivial: it may, for example,
be implemented with an editor macro.

In fact though, I'm really *not interested* in whether this argument
is correct -- the mere fact that it's a valid way of thinking
suggested to me that it was odd to deprecate the module, after
(presumably) having put it in for this very purpose (obfuscation) in
the first place.  However, if you're right in suspecting that
anti-crypto legistlation is always (or even usually) applied without
exception or waiver even to broken algorithms, then I agree it's
pointless -- after all, AES would serve just the same purpose!


John