8 comments

[ 6.0 ms ] story [ 29.1 ms ] thread
I have 1 philosophical and 1 implementation concern with this.

From a philosophical perspective I don't think looting dumpsters is a valid threat model - if someone gets your _unencrypted_ hard drive then the main contents are likely more damaging than cache content. The solution to that problem is full disk encryption by default on all devices, not application specific encrypted caches that do nothing to protect your data at large.

(That said, browser caches _are_ a privacy concern because they can be used to leak cross-origin information with timing attacks. This is why Chrome moved to per-origin caches rather than a global cache: https://chromestatus.com/feature/5730772021411840)

From an implementation perspective the encryption scheme uses unauthenticated aes-cbc. Some developer is going to use this cache in a web endpoint and trivially introduce a padding oracle attack.

My only immediate problem with this design is that AES-CBC doesn't provide authenticated encryption. AES-GCM would be a better choice.
(comment deleted)
The first implementation makes sense. However the second "hardened" one is completely broken, because now the cache is encrypted with the dictionary key...
Yes, instead a solution would be:

  encryptionKey = hash(salt + key)
  dictionaryKey = hash(encryptionKey)
It seems the blog was fixed now (without a note)
I think this approach may find good application to DHT, disabling DHT search engines from browsing items for censorship or copyright infriengement.