Pure Python Data Mangling or Encrypting

[Steven D'Aprano]

On Tue, 30 Jun 2015 10:19 pm, Jon Ribbens wrote:

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

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