Pure Python Data Mangling or Encrypting

[Steven D'Aprano]

On Sat, 27 Jun 2015 03:47 pm, Ian Kelly wrote:

[...]
>> Just make the AES encryption mandatory, not optional. Then the user
>> cannot upload unencrypted malicious data, and the receiver cannot read
>> the data. That's two problems solved.
> 
> And what if somebody else writes a competing version of the client
> software that doesn't bother with the encryption step at all? The
> point was that while encryption is expected, it cannot be assumed by
> the receiver, and in fact if the data is actually malicious, then it
> likely is not even being sent by the client software in the first
> place.

Right. As I said later in my post, you have a situation where neither party
can trust the other. I'm trying to store data on your computer, and I can't
trust you not to snoop on it, and you can't trust me not to send you
malware.


>> If the app does encrypt the data with AES before sending, then you don't
>> gain any benefit by obfuscating an encrypted file with a classical
>> monoalphabetic substitution cipher.
> 
> Only if the recipient can *trust* the sender to have performed the
> encryption, which it can't, no matter how mandatory the OP tries to
> make it.

True. But in either case, a classical (i.e. insecure) cipher doesn't do the
job.


>> Suppose that you hire an intern to write the "choose key" function, and
>> not knowing any better, he simply iterates through the keys in numeric
>> order, one after the other. So the first upload will use key 0, the
>> second key 1, the third key 2, and so on, until key 256! - 1, then start
>> again. In that case, predicting the next key is *trivial*. If I can work
>> out what key you send now (I just upload a file containing
>> "\x00\x01\x02...\xFF" to myself and see what I get), then I know what key
>> the app will use next.
> 
> If you upload a file to yourself, the result that you get will have no
> bearing on what key might be chosen when you upload a file to somebody
> else.

I admit it: I was getting a bit confused between attacks on the sender side
and attacks on the receiver side. The attacks I describe depend on the
sender's application doing encryption, but given that a malicious uploader
can just write their own client, that's redundant. There are easier attacks
on sender-side encryption. A back-and-forth argument on Usenet is no
substitute between a careful security analysis.

Can the sender attack encryption on the client side? Well, Chris has already
demonstrated one actual attack, based on a two-byte malicious payload. That
proves that the concept is at least possible, even if nobody uses DOS any
more.

As you go on to say:

> If the recipient system is using the system random to generate the
> key, then you can hack the application all you want, and it will give
> you precisely zero information about the state of the entropy pool on
> the remote system.

You're right. Are there other attacks where I, the sender, can get the
recipient to leak information about the key from the receiver?

Would you like to bet the answer is always No? I wouldn't.

Can you say "timing attack"?

http://codahale.com/a-lesson-in-timing-attacks/

Can you [generic you] believe that attackers can *reliably* attack remote
systems based on a 20µs timing differences? If you say "No", then you fail
Security 101 and should step away from the computer until a security expert
can be called in to review your code.

I'm not a security expert. I'm not even a talented amateur. *Every time* I
suggest that "X is secure", the security guy at work shoots me down in
flames. But nicely, because I pay his wages <wink>

If I say "such-and-such an attack is impossible", feel free to scoff and
laugh, because I'm probably wrong. But if I say "I don't know what it is,
but there's probably an attack you haven't thought of", unless you're a
security guy yourself, you probably ought to listen. (And if you are a
security guy, then you know how hard it is to secure against unknown
attacks.)

Tens of millions of zombie computers in botnets are proof that there are
exploitable attacks that programmers didn't think of. Or rather, *some*
programmers didn't think of them. Some other guys did.

I've said it before, and I will say it again: a classical substitution
cipher is trivially vulnerable to a preimage attack, strong crypto ciphers
are not. You're betting everything on the key being secret. If the keys
leaks, or is predictable, the attacker can successfully write malware on
the receiver's system. If the keys leak with AES, the system is still
secure against a preimage attack.


"Nobody will be able to guess the key, we don't need strong crypto."

"The Titanic is unsinkable, we don't need lifeboats for everyone."




-- 
Steven