Pure Python Data Mangling or Encrypting

[Devin Jeanpierre]

On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> But just sticking to the three above, the first one is partially mitigated
> by allowing virus scanners to scan the data, but that implies that the
> owner of the storage machine can spy on the files. So you have a conflict
> here.

If it's encrypted malware, and you can't decrypt it, there's no threat.

> Honestly, the *only* real defence against the spying issue is to encrypt the
> files. Not obfuscate them with a lousy random substitution cipher. The
> storage machine can keep the files as long as they like, just by making a
> copy, and spend hours bruteforcing them. They *will* crack the substitution
> cipher. In pure Python, that may take a few days or weeks; in C, hours or
> days. If they have the resources to throw at it, minutes. Substitution
> ciphers have not been effective encryption since, oh, the 1950s, unless you
> use a one-time pad. Which you won't be.

The original post said that the sender will usually send files they
encrypted, unless they are malicious. So if the sender wants them to
be encrypted, they already are.

"While the data senders are supposed to encrypt data, that's not
guaranteed, and I'd like to protect the recipient against exposure to
nefarious data by mangling or encrypting the data before it is written
to disk."

The cipher is just to keep the sender from being able to control what
is on disk.

I am usually very oppositional when it comes to rolling your own
crypto, but am I alone here in thinking the OP very clearly laid out
their case?

-- Devin