Pure Python Data Mangling or Encrypting

[Steven D'Aprano]

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.

* * * 

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

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



-- 
Steven