Pure Python Data Mangling or Encrypting

[Jon Ribbens]

On 2015-06-30, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, 30 Jun 2015 10:19 pm, Jon Ribbens wrote:
>> Eh? The game is over right there. I don't trust you, and yet
>> I have just given you my private data, unencrypted.
>
> Yes. That is exactly the problem. If the application doesn't encrypt the
> data for me, *it isn't going to happen*. We are in violent agreement that
> the sender needs to encrypt the data.

It's a good thing that he's said it will then.

> Randall has suggested that encryption is optional.

No he hasn't. You just keep creatively misreading what he says, for
some reason.

> It's not unreasonable to raise this issue.

It is unreasonable to raise it over and over again however,
especially when there's no reason at all to think it's relevant,
and nothing has changed from the last time you raised it.

> We can mitigate against the second attack by using a cryptographically
> strong hash function to detect tampering.

Not on the server you can't. If the attacker can edit the files he can
edit the hashes too.

> These *are* resistant to preimage attacks. If I give you a SHA512
> checksum, there is no known practical method to generate a file with
> that same checksum. If I give you a CRC checksum, you can.

Randall didn't suggest any usage of CRCs where preimage attacks are
relevant. You just made that bit up.

>>> - since you are using CRC, it is quite easy for me to ensure the
>>>   checksums match after inserting malware;
>> 
>> No, you have yet *again* misunderstood the difference between the
>> client and the server.
>
> This was described as a peer-to-peer application. You even stated that it
> was a "pretty obvious" use-case, a "peer-to-peer dropbox". So is it
> peer-to-peer or client-server?

Both. It sounds a bit like there are clients which upload files
to a cloud of servers which are peers of each other. But seriously,
is this the source of all your confusion? Even if all the nodes
are pure "peers" (which it doesn't sound like they are), any
particular file will still have a source node which is therefore
the "client" for that file. You're trying to draw a hard distinction
where there is none.

>> lol. I suspected as much. You and Johannes were even more wrong than
>> was already obvious.
>
> You "suspected as much"? Such a pity you didn't speak up earlier and
> explain that cryptographic ciphers aren't generally resistant to
> preimage attacks.

I think you're misusing that phrase. But taking what you meant,
I suspected it was true (would they be reistant, after all?)
but I couldn't be bothered to check because the whole "crypto" bit
was a complete red-herring in the first place. The original discussion
wasn't about crypto, all the discussion about that was only because
you and Johannes wrongly insisted it was necessary.