On 2015-06-30, Steven D'Aprano <st...@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. -- https://mail.python.org/mailman/listinfo/python-list
