That's an amazing attack which is even more impressive for being from 2005. It does make sense that in an algo as light as AES, cache misses would stick out like a sore thumb.
While I don't think this sort of attack works in fill mode (because the timing granularity is huge), it could theoretically work in accrual mode, to the extent that one might be able to cut the sequence hash space in half or better, provided that the client app sent a sideband signal to the attacker between unique hash occurrences, and assuming some predictability of cache contents. I don't think that's useful posttrapdoor, but it's a vuln I didn't think of, so I do take your general point seriously. Russell Leidich On Thu, May 28, 2015 at 2:20 AM, Naveen Nathan <[email protected]> wrote: > > My contention is that those processes are too hard to model in any > > realistic OS context. But maybe there's a really simple but useful > system > > in which that's not the case. > > It seems unbelievable to do a key recovery attack based by measureing > cache timing of AES, yet lo and behold we have attacks that can exploit > this over a network [1]. > > Just because you don't know how to model these processes or they are too > hard to you, > doesn't mean it isn't something in the realm of feasibility of a more > powerful > adversary. > > [1]: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
