 Thank you again for the opportunity to tell you about joint work with my co-authors Daniel Genkin, Leif Pachmanov and Yvonne Yorom about cash attacks. So cash attacks are very powerful cryptanalytic technique exploiting contention for low-level hardware resources, particularly the code and data cases of modern CPU. It's essentially oblivious to process confinement and virtualization mechanism and it has been shown to be a devastating way to extract keys across process and virtual machine boundaries. However, because it exploits low-level effects, attacks use low-level code to access the low-level resources and this requires native code execution. Now how would an attacker get to run their native code on the same platform as a victim? Well, if you look at the prior literature, it makes perfect sense in cloud setting, virtualization, multi-tenancy, multi-user servers and so on. But what about the typical end-user platforms, single-user on their own, simple device? They used to just download random crap from the internet and run it, but nowadays users are finally getting reluctant to install arbitrary native applications and they are discouraged to do so actively by the operating systems and increasingly application codes run within browsers, within web pages or browser plugins where they are sandboxed subject to the same origin policy and crucially run as interpreted code like JavaScript. Moreover, we are seeing increasing popularity of lockdown platforms that just run a web browser, things like Chromebook running Chrome OS claim to be the safest computer one can buy. So our cache attacks pertinent to such end-user settings and we show a resounding yes. Here's a typical scenario. The user is running Chrome on their Chromebook and opening Gmail in their web browser and then they're using a web-based implementation of OpenPGP called end-to-end developed by Google to decrypt their secret emails. So far, so good. In the background, there is some tab on some dubious pirate movie website that displays an advertisement that we put in that ad service which runs some code that proves the cache and extracts the secret key from this OpenPGP instance rather than running in that other tab, leading to full key extraction. So we have this very convenient deployment vector of a malicious website or a pop-up under advertisement or any other way to run code in the user's browser. It doesn't exploit any vulnerability, any bug. Everything is still subject to confinement but the cache attacks still work. We implement these attacks using portable native code supported by Chrome. You can think about it as a particularly efficient version of JavaScript and actually it's being standardized now into a replacement called SM.js or WebAssembly that has essentially the same properties. In order to run the ad cache attack from such portable code, there are many challenges to be surmounted including the browser's memory mapping, the ever-changing dynamic allocation and garbage collection, accurate timing sources, the lack of flash instructions, and the overhead of running non-native code. We have surmounted all of these and successfully attacked several implementations including full key extraction from Google's end-to-end implementation of OpenPGP, OpenPGP.js, another implementation in JavaScript, and the curve 2559 implementation of a library called Elliptic, which is particularly interesting because it uses this well-designed curve and its implementation is supposedly a constant time on Gomorrah ladder implementation and yet it is vulnerable because somewhere in the translation from their high-level JavaScript code to the machine code something gets optimized away and we can detect that in the code cache. This applies to the Chromebook lockdown platform as well as other platforms running Chrome and as we see cache-based key extraction attacks are possible on end-user devices including the latest and greatest ones including lockdown platforms and their doable buy and on non-native code. You can read all about it in our paper. Thank you.