Pure Python Data Mangling or Encrypting

[Randall Smith]

On 06/29/2015 10:00 PM, Steven D'Aprano 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;
> - and record the checksum for later;
> - I insert malware into your file;
> - you retrieve the file from me;
> - if the checksum matches what you have on record, you accept the file;
> - since you are using CRC, it is quite easy for me to ensure the
>    checksums match after inserting malware;
> - and I have now successfully injected malware into your computer.
>
> I'm making an assumption here -- I assume that the sender records a checksum
> for uploaded files so that when they get something back again they can tell
> whether or not it is the same content they uploaded.

Yes.  The client software computes sha256 checksums.

>
> * * *
>
> By the way, regarding the use of a substitution cipher, I spoke to the
> crypto guy at work, and "preimage attack" is not quite the right
> terminology, since that's normally used in the context of hash functions.
> It's almost a "known ciphertext attack", but not quite, since that
> terminology refers to guessing the key from the ciphertext.
>
> 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.
>
> His comment was, "don't leak the key".

I'm pretty sure all encryption hinges on guarding the key.

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


And again, that's why the client (data owner) uses AES.