Pure Python Data Mangling or Encrypting

[Devin Jeanpierre]

On Thu, Jun 25, 2015 at 2:25 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>> 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.
>
> The OP *hopes* that the sender will encrypt the files. I think that's a
> vanishingly faint hope, unless the application itself encrypts the file.
>
> Most people don't have any encryption software beyond password-protecting
> zip files. Zip 2.0 legacy encryption is crap, and there are plenty of tools
> available to break it. Winzip has an extension for 128-bit and 256-bit AES
> encryption, both of which are probably strong enough unless you're targeted
> by the NSA, but the weak link in the chain is the idea that people will
> encrypt the software before sending it. Even if they have the tools,
> laziness being the defining characteristic of most people, they won't use
> them.

You're right, I was supposing that since they wrote the server, they
also wrote the client, and were just protecting from the protocol
itself being weak.

> I know that the OP doesn't propose using ROT-13, but a classical
> substitution cipher isn't that much stronger.

Yes, it is. It requires the attacker being able to see something about
the ciphertext, unlike ROT13. But it is reasonable to suppose that
maybe the attacker can trigger the file getting executed, at which
point maybe you can deduce from the behavior what the starting bytes
are...?

> I don't think any of us *really* understand his use-case or the potential
> threats, but to my way of thinking, you can never have too strong a cipher
> or underestimate the risk of users taking short-cuts.

This is truth. It would be nice if something like keyczar came in the stdlib.

(Otherwise, users of Python take shortcuts and use randomized
substitution ciphers instead of AES.)

-- Devin