4 ms·
Self-Encrypted Cache Structure
- Loranubi 7y agoIf I am not mistaken, https://eprint.iacr.org/2019/1126 https://eprint.iacr.org/2019/1126 talks about this.
- arkadiyt 7y agoI 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 7y agoMy only immediate problem with this design is that AES-CBC doesn't provide authenticated encryption. AES-GCM would be a better choice.
- deleted 7y ago[deleted]
- Loranubi 7y agoThe first implementation makes sense. However the second "hardened" one is completely broken, because now the cache is encrypted with the dictionary key...
- Snawoot 7y agoI think this approach may find good application to DHT, disabling DHT search engines from browsing items for censorship or copyright infriengement.