Paul Rubin phr-pycrypt at nightsong.com
Thu May 30 19:39:46 CEST 2002

For long strings, the speed of HMAC will be limited by the speed of
the SHA implementation.  For short strings, the hmac from p2.py should
be quite a bit faster than the Python 2.2 hmac.py, but one in C will
be even faster.

There's a very fast SHA implementation included with OpenSSL, that
you could compare with Python's implementation.  Type "openssl speed
sha" to run a benchmark.  Again, there's lots of overhead for short
strings.  "2M/sec" is uninformative unless the string length is

My guess is that Python's SHA implementation isn't super-efficient but
it's probably not too bad.

p2.py is intended to supply an encryption function in pure-Python
environments where you can't load a C module.  Of course it's better
to use an AES module if one is available.  I'm still travelling but
will return next week and should be able to do something about the AES
module when I get back.

I don't mind if you adapt p2.py's HMAC implementation for your own
module, but I'd appreciate a credit in your source file if you do
that.  FWIW, I also have a replacement hmac.py (i.e. one that supplies
the same OO interface as Python 2.2's HMAC module) that I'll put on my
web site when I get back, if anyone wants it.  I was thinking of
submitting it to Guido since it should be somewhat faster than the
original (though not as fast as a C function).

Note that the OO stuff probably slows things down considerably for
short strings.  You may be better off using a string-function
interface like the one in p2.py rather than the OO interface in your
TMDA file.

Finally, if your application needs a very fast MAC but doesn't have to
be HMAC-SHA compatible, you might look at Dan Bernstein's hash127
function, <http://cr.yp.to/hash127.html>.  It's considerably faster
than MD5 or SHA, and has a security proof that's better than either.


More information about the python-crypto mailing list