>>>> Do you have any comment from Intel on the concerns regarding the >>>> scattering technique >>>> (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)? First, a comment: it is difficult to actually understand the precise claim by the authors, from these 6 slides. The code snippet does not include sufficient information to determine what the experiment really is. With this disclaimer, my understanding is this: the authors of the presentation claim that accessing different locations on a cache line shows different latencies – depending on the location (within the cache line). The graph shows a *significantly* larger latency for doubleword #0. As a result, they insinuate that the scattering-gathering method for accessing tables does not protect against side channel analysis.
This, however, seems to me to be incorrect. Perhaps what the experiment shows is due to “cache line splits”, where the data that is being accessed does not reside completely in a single cahce line. For example, when aligned on 56 bytes, and reading 64-bit quadwords, the first one (say Q0) is in one cache line and the rest are in another. So, when flushing (only) the cache line that holds Q0, subsequent reading of Q0 would be “slow” but reading the rest would be fast. It is not possible to see how the array was aligned in the discussed presentation, because the code snippet does not include this part. Anyway, this phenomenon is not a vulnerability - it is only about a proper implementation of the gather/scatter method: the elements of the table simply need to be naturally aligned in a way that every single element belongs to the same cache line. The programmer needs make sure that the elements of the table are naturally aligned (e.g., aligned (64)). As long as there are no cache line splits, there should be no timing difference between accesses to a cache line. Shay -----Original Message----- From: Bodo Moeller via RT [mailto:r...@openssl.org] Sent: Friday, November 08, 2013 12:09 To: Gueron, Shay Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms > Here is an updated version of the patch. > > Addressing a) "pointer to the function" (to select ADCX/ADOX) and b) > multiple points addition > > There is (only) ~1% performance deterioration in due to the pointer > being passed now, instead of (originally) being static. You can choose > which style is preferable. > Thanks! Alternatives would be (a) using a new lock for safe static initialization, or (b) more code duplication to avoid the need for an explicit pointer (there could be two separate implementations for the higher-level routines). However, given the 1% performance penalty, that's a minor issue at this point. Do you have any comment from Intel on the concerns regarding the scattering technique (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)? Bodo --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
