Rosen Penev wrote:
One downside of this is that in the case of iterated hashes(PBKDF2) this
only speeds up the first iteration. I do not believe that TLS uses
iterated HMAC-SHA1.
And that is a good thing! Anything that speeds up or otherwise reduces
the computation effort of PBKDF2 only weaken its purpose.
One of the primary goals of PBKDF2 is to have a fixed computation cost
that can be adjusted by setting an appropriate iteration level. This is
used to store a tiny (think <1Kb) amount of fixed data from long periods
of time (think days or years).
It is good to hear that a bunch of GPUs can not usefully speed up
PBKDF2, working as intended then.
On the subject of precomputing hash digests...
OpenSSL used to allow the standard C API to be used in this way that the
internal state of a digest could be snapshot/saved by using memcpy().
At some point (maybe around 0.9.7 to 0.9.8) the ENGINE API got its teeth
into the main C APIs and broke this by doing indirection of internal
data structures.
The scenarios from the late 1990s that did this (like RADIUS), did not
use a lot of input data and on modern CPU might as well run all ~64bytes
of data into the digest each time as we are no longer CPU bound in this
area.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
