Pure Python Data Mangling or Encrypting

[Devin Jeanpierre]

On Sat, Jun 27, 2015 at 6:18 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, 28 Jun 2015 06:30 am, Devin Jeanpierre wrote:
>
>> On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>>> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>>>
>>>> On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano <steve at pearwood.info>
>>>> wrote:
>>>>> Now you say that the application encrypts the data, except that the
>>>>> user can turn that option off.
>>>>>
>>>>> Just make the AES encryption mandatory, not optional. Then the user
>>>>> cannot upload unencrypted malicious data, and the receiver cannot read
>>>>> the data. That's two problems solved.
>>>>
>>>> No, because another application could pretend to be the file-sending
>>>> application, but send unencrypted data instead of encrypted data.
>>>
>>> Did you stop reading my post when you got to that? Because I went on to
>>> say:
>>
>> At that point I quit in frustration, yeah.
>>
>>> "Actually, the more I think about this, the more I come to think that the
>>> only way this can be secure is for both the sending client application
>>> and the receiving client appl to both encrypt the data. The sender can't
>>> trust the receiver not to read the files, so the sender has to encrypt;
>>> the receiver can't trust the sender not to send malicious files, so the
>>> receiver has to encrypt too."
>>
>> When you realize you've said something completely wrong, you should
>> edit your email.
>
> If both the sender and receiver encrypt the data, how is is "completely
> wrong" to say that encrypting data should be mandatory?

That isn't what I was calling completely wrong. This is:

>>>>> Just make the AES encryption mandatory, not optional. Then the user
>>>>> cannot upload unencrypted malicious data, and the receiver cannot read
>>>>> the data. That's two problems solved.

The user can still upload unencrypted malicious data by writing their
own client that doesn't have mandatory AES encryption.

You realized this later in the email, apparently, which is why you
should have edited your own email to delete your original, insecure,
suggestion. :(

That said, I appreciate the work you've done here asking for a
specific threat model and pushing back on the idea that it's up to
python-list to prove something is insecure, not the other way around.
That's important. I think, for the same reasons, it's also important
to be really careful what cryptosystems we discuss, and not suggest or
appear to suggest ones that won't work.


P.S. FWIW, the base64 idea has a lot of promise and is probably
fundamentally better than a crypto algorithm. With something along the
lines of base64 -- say, encoding a file using just the letters 'a' and
'b' -- one might try to make it it literally impossible to write "bad"
things to disk, whereas with any crypto, it is always possible to
obtain the key, so one has to be careful with key management to
prevent/mitigate that.  (One might add: why not both? Beats me. I like
using extension modules.)

P.P.S.: of course, I'm not an expert.

-- Devin