On Tue, 30 Jun 2015 10:19 pm, Jon Ribbens wrote: > 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.
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. I think Randall has been somewhat less than clear about what the application actually does and how it works. He probably thinks he doesn't need to explain, that its none of our business, and wishes we'd just shut up about it. That's his right. It's also my right to discuss the possible security implications of some hypothetical peer-to-peer dropbox-like application which may, or may not, be similar to Randall's application. Whether Randall learns anything from that discussion, or just tunes it out, is irrelevant. I've already learned at least one thing from this discussion, so as far as I'm concerned it's a win. Randall has suggested that encryption is optional. It isn't clear whether he means there is an option to turn encryption off, or whether he means I can hack the application and disable it, or write my own application. I don't expect him to be responsible for rogue applications that have been hacked or written independently, which (out of malice or stupidity) don't encrypt the uploaded data. But I think that it is foolish to support an unencrypted mode of operation. It's not unreasonable to raise this issue. The default state of security among IT professionals is something worse than awful: https://medium.com/message/everything-is-broken-81e5f33a24e1 One of Australia's largest ISPs recently was hacked, and guess how they stored their customer's passwords? Yes, you got it: in plain text. There is no security mistake so foolish that IT professionals won't make it. > Checksums don't even come into it, we have failed utterly at step 1. *shrug* You're right. But having failed at step 1, there are multiple attacks that can follow. The first attack is the obvious one: the ability to read the unencrypted data. If you can trick me into turning encryption off (say, you use a social engineering attack on me and convince me to delete "the virus crypto.py"), then I might inadvertently upload unencrypted data to you. Or maybe you find an attack on the application that can fool it into dropping down to unencrypted mode. If there's no unencrypted mode in the first place, that's much harder. Earlier, Chris suggested that the application might choose to import the crypto module, and if it's not available, just keep working without encryption. This hypothetical attack demonstrates that this would be a mistake. It's hard for an attacker to convince a naive user to open up the application source code and edit the code. It's easier to convince them to delete a file. Or, the application just has a bug in it. It accidentally flips the sense of the "use encryption" flag. That's a failure mode that simply cannot occur if there is no such flag in the first place. If our attacker has managed to disable encryption in the sender's application, then they can not only read my data, but tamper with it. These are *separate attacks* with the same underlying cause. I can mitigate one without mitigating the other. We can mitigate against the second attack by using a cryptographically strong hash function to detect tampering. 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. (Naturally the checksum has to be under the sender's control. If the receiver has the checksum and the data, they can just replace the checksum with one of their choosing.) That's a separate issue from detecting non-malicious data corruption, although of course a SHA512 checksum will detect that as well. >> - 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? In any case, since Randall has refused to go into specific details of how his application works, as is his right, we can treat this as an intellectual exercise for how it *might* work. If such an application keeps a checksum of the files uploaded, it should be one which can detect deliberate tampering and not just accidental corruption. >> 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. 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. In any case, I have learned something from this discussion, which makes it worthwhile. -- Steven -- https://mail.python.org/mailman/listinfo/python-list