Compression Oracle Attacks

[kousu]

Hi there,

The whitepaper claims you do both e2e encryption and also incremental versioning.

I believe this combination may leave you open to a compression oracle attack: anytime you combine encryption with compression you are open to a chosen plaintext attack, unless you pad out your messages carefully (defeating the purpose of compression).

[kousu]

Actually maybe I'm raising a false alarm. Reading your whitepaper more, it looks like you don't decide what to send based on, you just increment some metadata and check if it matches or not. So every update will trigger a sync, no matter what it contains, revealing only the size of the new data. Does that seem right to you?

Combining zip or gzip with dat might be vulnerable to compression oracles, though. Maybe you should add a note about that?

[bnewbold]

Hi @kousu, thanks for raising this concern!

I don't understand the first paragraph of your second comment, could you rephrase it? ("what to send based on", "every update"). Also, could you clarify what such an attack would entail? Eg, is the attacker connecting to a peer node using a discovery key, but without access to the feed public key? In such a case the attacker does control the nonce value, but I do don't believe that a compression oracle attack would apply in that situation to derive any information about the pubic key or feed contents.

The dat protocol itself does not currently use compression at any layer of the stack; are you concerned about users placed compressed data inside a hypercore feed or a dat archive? I can't see how either case would impact the security of protocol-layer secrets or protections, but I may be misunderstanding.