rotor alternative?

[Dave Brueck]

Peter wrote:
> Dave Brueck wrote:
> >
> > Rotor was nice because for very little costs in terms of CPU / coding
nuisance
> > you could protect semi-sensitive data from nearly everyone. Sure it's
> > strength-per-bit-of-key-size doesn't stack up well against more modern
> > algorithms
>
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms?

I disagree, I don't think that's the issue at all. Rotor is far, far weaker
than even DES, but both take far, far more effort to crack than practically
anyone is willing to put forth, and I don't tend to care about that 0.0001% of
the people who do want to invest the effort.

> My guess is that it's so insecure that most people wouldn't really want
> to use it if they knew how insecure it was, or they would actually decide
> that something like XORing the data is actually adequate and stick with
> that.

Maybe so, maybe not. Here's one counter data point: me. :) FWIW, rotor isn't
_that_ much more complicated that XORing your data, the main difference being
that the data you XOR it with changes after each byte. Probably the bulk of the
benefit of rotor is that it's present, documented, and maybe that it's in C so
it's fast.

If someone is trying to protect their data but haven't done enough of their
homework to know that rotor versus e.g. AES is incredibly weak, odds are they
aren't going to have a secure system *at all* anyway, no matter how strong
encryption library they use - they'll probably leave the key totally exposed or
some such mistake. If a person using it _doesn't_ know how insecure it is, then
even if you give them AES to make the front door impenetrable, most likely all
the windows will still be wide open.

> I suspect that those who want rotor actually want something stronger
> than it really is, but could actually get by with something even weaker
> than it is (though they don't believe that), and leaving it out of the
> standard library isn't a real problem, just a perceived one.

How's this: it would be really great to have a key-based data obfuscator (read:
weak encryptor) ship as a standard part of Python. I'll concede that if rotor
keeps somebody out, a simple data munge like XOR probably would too (although
you're getting a little closer to the point where hex editor-using crackers can
play whereas rotor requires a programmer cracker). The difference is that a
standard module like rotor hits the sweet spot in terms of diminishing returns
of effort vs security, so if you're going to settle for that level of security
and have it ship as a standard module, why _not_ just use rotor?

-Dave