(Bodo Moeller) via RT wrote: > Tom Wu via RT <[EMAIL PROTECTED]>: > > >> In the case where the blinding struct is owned by >>a different thread from the one doing an RSA op, the code has to do a >>modexp and a mod inverse, as opposed to the two squarings that the >>update normally does. > > > These two squarings should be changed, though -- OpenSSL should use a > random new blinding factor after a couple of RSA secret key operations > instead of predictably updating the factor (I didn't want to change > all of this at once). So the update code will be slower in the > future; not every time, but sometimes.
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 also wonder if slowing down blinding would weaken the rationale for turning it on all the time when doing RSA? > > >> 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. > > 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. Tom -- Tom Wu Chief Security Architect Arcot Systems (408) 969-6124 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
