4 ms·
THREAT MODEL > Like earlier, we assume our attacker embeds some malicious JavaScript in a webpage the victim is browsing for several minutes. The vic- tim runs
by miohtama 3y ago
THREAT MODEL
> Like earlier, we assume our attacker embeds some malicious JavaScript in a webpage the victim is browsing for several minutes. The vic- tim runs a GPU-based AES implementation that can be queried for encryption with a chosen plaintext and key.
Nobody runs a GPU-based AES implementation, so I feel the thread model and thus the assumptions of the paper are on a quite shaky ground.
- 2OEH8eoCRo0 3y agoDoes it matter when the purpose is to demonstrate a crack in WebGPU?
- olliej 3y agoIt does when the attack mechanism is a completely standard attack (cache eviction on aes tables) with an established solution (not running aes on shared resources, various masking operations, or simply doing the correct thing and using the system aes implementation or hardware). This attack is not wholly different from them saying “we made an aes implementation on the gpu and it leaked timing information”, yes it’s technically present, but the problem is not that you can’t tell the gpu to disable any predictors or caches, it’s that you’re using a wholly unsuited tool for a wholly inappropriate task with known hazards and expecting different outcome.