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 06:52 am, Randall Smith wrote:
>> Not sure why you posted the link.  The crc32 checksum is just to check
>> for possible filesystem corruption.  The system does periodic data
>> corruption checks.  BTRFS uses crc32 checksums also.  Please explain.
>
> The file system can trust that anything writing to a file is allowed to
> write to it, in doesn't have to defend against malicious writes. As I
> understand it, your application does.
>
> Here is the attack scenario I have in mind:
>
> - you write a file to my computer, and neglect to encrypt it;

Eh? The game is over right there. I don't trust you, and yet
I have just given you my private data, unencrypted. Checksums
don't even come into it, we have failed utterly at step 1.

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

> I was wrong: cryptographically strong ciphers are generally NOT resistant to
> what I described as a preimage attack. If the key leaks, using AES won't
> save you: an attacker with access to the key can produce a ciphertext that
> decrypts to the malware of his choice, regardless of whether you use
> AES-256 or rot-13. There may be other encryption methods which don't suffer
> from that, but he doesn't know of them off the top of his head.

lol. I suspected as much. You and Johannes were even more wrong than
was already obvious.

> The other threat I mentioned is that the receiver will read the content of
> the file. For that, a strong cipher is much to be preferred over a weak
> one, and it needs to be encrypted by the sending end, not the receiving
> end. (If the receiving end does it, it has to keep the key so it can
> decrypt before sending back, which means the computer's owner can just grab
> the key and read the files.)

Yes, that is utterly basic.