Hello, > http://eprint.iacr.org/2014/435.pdf > > Just wanted to make sure the LibreSSL team had seen this. Sorry about the > lack of proper formatting - I figure sending the issue here is considerably > more likely to get a response than OpenSSL's request tracker. > > Page 18, under Countermeasures -> Cache Flushing, shows their recommended > solution. It would probably make for additional good press to have LibreSSL > have a countermeasure in place long before OpenSSL.
Thanks for pointing this. There is not much we can do against this, but force the AES tables to be warm in the cache at the end of the operation by reading them in whole, and unfortunately this will have a performance impact. Clearing the whole cache would as well, but there might be a way to do the opposite and actually evict the AES tables from the cache. But this will require adding platform-specific code and I'm not really fond of adding more ifdefs to libcrypto at the moment. Note that this kind of covert channel attacks are not new, and are the reason why BN_mod_exp_mont_consttime() takes care having a constant cache footprint. It might be worth introducing ``consttime'' AES routines (and EVP routines on top of them) to limit the suffering to their callers, but since all the cloud/virtualization salesperson keep telling you that you don't need to adjust your code for it to run in a virtualized environment, this is probably a bad idea, because noone would use these functions.
