We were getting this error on Python 3.2:

    ERROR: runTest (Crypto.SelfTest.Hash.common.MACSelfTest)
    CMAC #17: NIST SP 800 38B D.7 Example 17
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "build/lib.linux-x86_64-3.2/Crypto/SelfTest/Hash/common.py", line 199, in runTest
        self.assertRaises(ValueError, h.hexverify, "4556")
      File "/home/dwon/py/pythons/python3.2/lib/python3.2/unittest/case.py", line 557, in assertRaises
        callableObj(*args, **kwargs)
      File "build/lib.linux-x86_64-3.2/Crypto/Hash/CMAC.py", line 323, in hexverify
        self.verify(unhexlify(hex_mac_tag))
    TypeError: 'str' does not support the buffer interface

This patch adds support for CMAC (RFC4493, NIST SP800-38B).

[dlitz@dlitz.net: Replaced MacMismatchError with ValueError]
[dlitz@dlitz.net: Whitespace fixed with "git rebase --whitespace=fix"]

The MAC unit tests assume that the MAC algorithm is
based on hash functions (HMAC).
Additionally, a single test vector is quite complex
in that it includes result for multiple tests (each
performed on the same data, but with different
hashes).

This patch simplifies the MAC unit test so that it does
not depend on hashes and a test vector is simply made up by:
* 1 input
* 1 result
* All parameters to pass to the new() function

[dlitz@dlitz.net: Replaced custom MacMismatchError with ValueError.]
[dlitz@dlitz.net: Replaced 'import *' with appropriate imports.]
[dlitz@dlitz.net: Whitespace fixed with "git rebase --whitespace=fix"]

In the current implementation, it is left up to the caller
to assess if the locally computed MAC matches the MAC associated
to the received message.

However, the most natural way to do that (use == operator)
is also deepy unsecure, see here:

http://seb.dbzteam.org/crypto/python-oauth-timing-hmac.pdf

With this patch, the new HMAC.verify() method accepts
the given MAC and perform the check on behalf of the caller.
The method will use constant-time code (still dependent on the length
of the MAC, but not on the actual content).

[dlitz@dlitz.net: Modified commit message subject line.]
[dlitz@dlitz.net: Whitespace fixed with "git rebase --whitespace=fix"]

The patch contains the following changes:

- Private RSA keys can be imported/exported in encrypted form,
  protected according to PKCS#8 and:

  * PBKDF2WithHMAC-SHA1AndDES-EDE3-CBC.
  * PBKDF2WithHMAC-SHA1AndAES128-CBC
  * PBKDF2WithHMAC-SHA1AndAES192-CBC
  * PBKDF2WithHMAC-SHA1AndAES256-CBC

  In addition to that, it is possible to import keys i the
  following weak formats:

  * pbeWithMD5AndDES-CBC
  * pbeWithSHA1AndRC2-CBC
  * pbeWithMD5AndRC2-CBC
  * pbeWithSHA1AndDES-CBC

- The following new module (and 1 new package) are added:

  * Crypto.Util.Padding for simple padding/unpadding logic
  * Crypto.IO._PBES for PBE-related PKCS#5 logic
  * Crypto.IO.PEM for PEM wrapping/unwrapping
  * Crypto.IO.PKCS8 for PKCS#8 wrapping/unwrapping

- All Object ID (OIDs) are now in dotted form to increase
  readability.

- Add AES support to PEM format (decode only).
  The PEM module can decrypt messages protected with AES-CBC.

- Update RSA import test cases.

- Updated to PKCS8 test cases

The pure Python wrappers around Crypto.Hash.* were convenient, but they
slowed down hash initialization by 4-7x.

There is a speed trade-off here: The MD5 and SHA1 objects are just
wrapped hashlib objects (or old-style md5/sha objects).  To maintain API
compatibility with the rest of PyCrypto, we still have to wrap them, so
they're slower to initialize than the rest of the hash functions.  If
hashlib ever adds a .new() method, we will automatically use hashlib
directly and gain the initialization speed-up.

This allows us to instantiate a new hash given only an existing hash
object.

In PyCrypto v2.5, the "oid" attribute was added to hash objects.  In
retrospect, this was not a good idea, since the OID is not really a
property of the hash algorithm, it's a protocol-specific identifer for
the hash functions.  PKCS#1 v1.5 uses it, but other protocols (e.g.
OpenPGP, DNSSEC, SSH, etc.) use different identifiers, and it doesn't make
sense to add these to Crypto.Hash.* every time a new algorithm is added.

This also has the benefit of being compatible with the Python standard
library's "hashlib" objects, which also have a name attribute.