from the conclusion it looks like the latest version of OpenSSL mitigates the attack: ''' One concrete mitigation strategy has been realized in OpenSSL 1.0 [1

from the conclusion it looks like the latest version of OpenSSL mitigates the attack: ''' One concrete mitigation strategy has been realized in OpenSSL 1.0 [18]. There, only the substitution table S is stored, and then the required multiplications within GF (28) are computed by using the following relations, which can be realized in a highly efficient way using the PCMPGTB instruction: +- -+ | +- | | | ff (int8_t) x > 0 | 2•x = (x << 1) ⊕ | 1b ∧ -+ | | | 0 (int8_t) x ≤ 0 | | +- | +- -+ = (x << 1) ⊕ (1b ∧ PCMPGTB(x, 0)) 3•x = 2 • x ⊕ x In this case, the required table contains 28 = 256 entries of 20 = 1 bytes each, and on standard x86-architectures with a cache-line size of 26 = 64 bytes we have that only l = 2 bits of each x∗ are leaked. Looking at Table 1 now shows that we have p3 = 1, i.e., every k∗ ∈ {0, 1}4·2 is a valid partial key-column candidate for every x∗ and y∗ . For this reason, our key search algorithm does not work anymore. Because of the large prevalence of AES another mitigation strategy is currently embarked by software vendors. Namely, they are increasingly often offering hardware support of AES in their chips, e.g., [25], rendering access-driven cache attacks impossible. '''