
Self-Encrypted Cache Structure - nayuki
https://www.nayuki.io/page/self-encrypted-cache-structure
======
Loranubi
If I am not mistaken,
[https://eprint.iacr.org/2019/1126](https://eprint.iacr.org/2019/1126) talks
about this.

------
arkadiyt
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](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.

------
CiPHPerCoder
My only immediate problem with this design is that AES-CBC doesn't provide
authenticated encryption. AES-GCM would be a better choice.

------
Loranubi
The first implementation makes sense. However the second "hardened" one is
completely broken, because now the cache is encrypted with the dictionary
key...

~~~
susano
Yes, instead a solution would be:

    
    
      encryptionKey = hash(salt + key)
      dictionaryKey = hash(encryptionKey)

~~~
Loranubi
It seems the blog was fixed now (without a note)

------
Snawoot
I think this approach may find good application to DHT, disabling DHT search
engines from browsing items for censorship or copyright infriengement.

