Pure Python Data Mangling or Encrypting

[Jon Ribbens]

On 2015-06-25, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>> If it's encrypted malware, and you can't decrypt it, there's no threat.
>
> If the *only* threat is that the sender will send malware, you can mitigate 
> around that by dropping the file in an unencrypted container. Anything good 
> enough to prevent Windows from executing the code, accidentally or 
> deliberately, say, a tar file with a custom extension.

That won't stop virus scanners etc potentially making their own minds
up about the file.

> But encrypting the file is also a good solution, and it prevents the storage 
> machine spying on the file contents too. Provided the encryption is strong.

How would the receiver encrypting the file after receiving it prevent
the receiver from seeing what's in the file?

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

Yes, the application itself encrypts the file. Haven't you been
reading what he's saying?

> The sender has a copy of the application? Then they can see the type of 
> obfuscation used. If they know the key, or can guess it, they can take their 
> malware, *decrypt* it, and send that, so that *encrypting* that file puts 
> the malicious code on the disk.

Not if they don't know the key they can't.

> E.g. suppose I want to send you an insult, but I know your program 
> automatically ROT-13s the strings I send you. Then I send you:
>
> 'lbhe sngure fzryyf bs ryqreoreevrf'
>
> and your program ROT-13s it to:
>
> 'your father smells of elderberries'
>
> I know that the OP doesn't propose using ROT-13, but a classical 
> substitution cipher isn't that much stronger.

Replace "ROT-13" with "ROT-n" where 'n' is a secret known only to the
receiver, and suddenly it's not such a bad method of obfuscation.
Improve it to the random-translation-map method he's actually using
and you've got really quite a reasonable system.

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

The use case is pretty obvious (a peer-to-peer dropbox type thing) but
it does appear to be being misunderstood. This isn't actually a crypto
problem at all and "users taking short-cuts" isn't an issue.