Tom Wu via RT <[EMAIL PROTECTED]>: > Bodo Moeller via RT wrote: >> The next round of snapshots (20030402, to appear at >> ftp://ftp.openssl.org/snapshot;type=d in about six hours) >> should solve the multi-threading problems. Please test them when they >> are available.
> The good news is that the fix in the snapshot fixes the problem, but the > bad news is that it seems to kill performance in my benchmarks. On a > P3-750 running Linux, I get 106 RSA sign/s (1024-bit) with my patch, > regardless of the number of simultaneous threads. With the snapshot > fix, I get 102 RSA sign/s with one thread, but if I try with 2 or more > threads it drops down to 81 sign/s. > > It's quite possible that I've misconfigured something on my own end, but > I suspect that it is more likely that the local blinding operation is > slowing things down. Yes, surely this is what is happening, local blinding is somewhat expensive. > 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. > 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. 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). -- 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]
