Tom Wu via RT <[EMAIL PROTECTED]>: > (Bodo Moeller) via RT wrote: >> Tom Wu via RT <[EMAIL PROTECTED]>:
> Is there any established wisdom on the security implications of > refreshing the blinding factor? Assuming that the initial blinding > value had sufficient entropy and was unknown to an attacker, is there > still some way to carry out a timing attack given the knowledge that the > host is just squaring A after each RSA operation? I am not aware of descriptions of such attacks. Maybe it would even suffice to randomly square or cube the factor to avoid potential attacks, but better safe than sorry ... > I also wonder if slowing down blinding would weaken the rationale for > turning it on all the time when doing RSA? Well, in any case you can still turn it off if it is too slow. >>> I believe that on most if not all platforms, the >>> cost of putting critical sections around the blinding convert/update >>> will be drastically smaller than the cost of the extra local blinding >>> computation. >> This depends: on a single-processor machine, indeed additional locking >> should usually be faster than using local blinding; but for >> multi-processor systems, the cost of locking could be quite high. > I just tried benchmarking the snapshot code against my earlier patch on > an 8-way P3-700 server (Win2K AS). My patch gets ~100 RSA sign/s > (1024-bit) with a single thread and peaks at ~790 RSA sign/s with 8 > threads. The 0402 snapshot also starts at ~100 RSA sign/s with 1 thread > and peaks at ~650 RSA sign/s with 8 threads. Thanks for the timings. One thing to take into account when interpreting these is that some additional random blinding should be added to your patch; maybe once in ten or hundred RSA operations, so the timing difference would not really change a lot. A more important aspect is that you are comparing just the case that multiple threads do share an RSA structure. A different scenario is that you have multiple threads with *individual* RSA structures -- then the snapshot version will be very fast while the version with locking will be unnecessarily slowed down because the locks are global. This is why we are trying to avoid excessive locking. >> There are some strategies that could be used to make blinding faster >> without expensive locking, but these would require incompatible >> changes to the RSA and/or BN_BLINDING structures (the addition of >> thread_id is an incompatible change in theory, but it's one that does >> not directly affect applications). > As for what to do for the short term in 0.9.6j or 0.9.7b, is there any > chance of using my original patch with the _r methods? It doesn't > change either the RSA or BN_BLINDING structures at all, and seems to > give the least slowdown on both single and multi-processor systems. > Perhaps the "always square A" behavior should be the default if it is > "good enough" to block the obvious timing attack, with future options to > enable random refresh strategies if the caller wants to do a > performance/security tradeoff. One idea to consider is to include a second BN_BLINDING slot with each RSA object: the first BN_BLINDING object would be single-threaded (as in the current snapshots), the second one would be shared between all the other threads (and require locking). The major problem is how to do this without harming compatibility too much. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
