2

As mentioned in this particular answer, compressing data before encryption may lead to the CRIME attack, especially if the hacker has collected many similar versions of the transmitted data.

Let's use the following example for this particular security case:

  • Bob is using an encrypted personal diary program which is stored in a file which is encrypted using AES-256 in CBC mode with a SHA-256 HMAC (or AES-256 in GCM mode).
    • The journal compresses entry text using LZ or DEFLATE compression upon saving them.
    • The journal file structure is a fairly simple BSON tree (think JSON, but binary so no need to escape strings/etc.) which simply compresses the actual journal text upon file saving, but not the journal entry titles, dates, etc.
  • Bob stores this file in a Dropbox folder which is synced across his machines.
  • One of Bob's machines is compromised and Oscar now has access to his Dropbox account.
  • Oscar can download all history for the journal from Dropbox.

What is the main attack surface, if any, for Oscar? Does having compressed data in the encrypted journal file offer compromises which Oscar can exploit?

Community
  • 1
Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75
  • 2
    CRIME relies on the attacker being able to force Bob to compress then encrypt plaintext of his choosing and being able to observe the different results... I don't think it's the case in your scenario. – Bruno Rohée May 23 '14 at 17:15
  • If I know that Bob wrote an entry on 2014/05/01, can't I expect that the date will be contained in the encrypted file? Does only the compressed parts of the plaintext suffer from the attack? – Naftuli Kay May 23 '14 at 17:22
  • The date is in the file only if someone puts in it, on the file system it's metadata and not part of the file. And in any case, that would only be a known plaintext attack which doesn't seem to be an issue in what we are discussing. – Bruno Rohée May 23 '14 at 18:06
  • As mentioned above, the journal entry date _is_ embedded in the file, however this shouldn't be a problem, as you mentioned as it should hopefully not be a known plaintext attack. – Naftuli Kay May 23 '14 at 18:07

2 Answers2

2

As far as I understand your scheme is not vulnerable to CRIME in the scenario you present, CRIME style attacks needing the attacker to be able to induce Bob to compress then encrypt material of his choosing, then being able to observe at the very least the size of the result.

However, if I was to attack your scheme, I'd target the part you left out : key generation and more generally key lifecycle.

If you generate your encryption key from a password, do you enforce strong password and do you use a good key derivation function, are you sure you e.g. don't lose entropy with some silly mistakes like playing with encoding or somehow normalizing the password?

Is the key randomly generated (it then begs the question, how good is your randomness source) then itself protected by another mechanism, and how strong is it?

You mention Bob machine being broken into, are you sure no key material is left behind? Do you lock key material in memory? Do you zero it properly once you are done with it? Do you avoid passing it on the command line?

Bruno Rohée
  • 5,221
  • 28
  • 39
2

CRIME is a type of chosen-plaintext attack where most but not all of the plaintext is under the attacker's control, and the attacker desires to discover what the rest of the plaintext is. Your scenario is completely immune to this sort of attack, since the attacker has no control over the plaintext.

Mark
  • 34,390
  • 9
  • 85
  • 134