summaryrefslogtreecommitdiff
path: root/lib/Crypto/Hash
Commit message (Collapse)AuthorAgeFilesLines
* hexverify: Fix handling unicode strings on Python 3.2Dwayne Litzenberger2013-10-202-2/+2
| | | | | | | | | | | | | | | | 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
* CMAC: raise TypeError instead of ValueError when ciphermod is missing or ↵Dwayne Litzenberger2013-10-201-2/+3
| | | | | | | | unusable This makes the CMAC module behave more like most Python functions do when a required argument is missing, and reserves ValueError for a MAC failure.
* Add support for GCM mode (AES only).Legrandin2013-10-201-35/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main change done by this commit is adding support for MODE_GCM (NIST SP 800 38D). Test vectors are included. The mode uses a C extension (Crypto.Util.galois._ghash) to compute the GHASH step. The C implementation is the most basic one and it is still significantly (5x times) slower than CTR. Optimizations can be introduced using tables (CPU/memory trade-off) or even AES NI instructions on newer x86 CPUs. This patch also simplifies Crypto.Cipher.blockalgo.py by: * removing duplicated code previously shared by digest() and verify(). * removing duplicated code previously shared by Crypto.Hash.CMAC and Crypto.Cipher.block_algo (management of internal buffers for MACs that can only operate on block aligned data, like CMAC, CBCMAC, and now also GHASH). [dlitz@dlitz.net: Included changes from the following commits from the author's pull request:] - [9c13f9c] Rename 'IV' parameter to 'nonce' for AEAD modes. - [ca460a7] Made blockalgo.py more PEP-8 compliant; The second parameter of the _GHASH constructor is now the length of the block (block_size) and not the full module. [dlitz@dlitz.net: Replaced MacMismatchError with ValueError] [dlitz@dlitz.net: Replaced ApiUsageError with TypeError] [dlitz@dlitz.net: Replaced renamed variable `ht` with original `h`] [dlitz@dlitz.net: Whitespace fixed with "git rebase --whitespace=fix"]
* Add support for CMACLegrandin2013-10-202-1/+279
| | | | | | | 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"]
* Add HMAC.verify() and HMAC.hexverify() with constant-time comparisonLegrandin2013-10-201-2/+53
| | | | | | | | | | | | | | | | | | | 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"]
* Update RIPEMD documentation (deprecated; see RIPEMD160)junk/masterDwayne Litzenberger2013-07-141-1/+3
|
* Hash: Speed up initialization by removing pure-Python wrappershash-speedup-wipDwayne Litzenberger2013-02-1710-794/+94
| | | | | | | | | | | | 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.
* Hash: Generic Crypto.Hash.new(algo, [data]) functionDwayne Litzenberger2013-02-171-0/+119
| | | | | This allows us to instantiate a new hash given only an existing hash object.
* Hash: Remove "oid" attributes; add "name" attributeDwayne Litzenberger2013-02-1710-90/+6
| | | | | | | | | | | | 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.
* Hash: Rename SHA->SHA1 and RIPEMD->RIPEMD160 (2/2)Dwayne Litzenberger2013-02-162-0/+48
| | | | | | | | | These algorithm names were confusing, because there are actually algorithms called "SHA" (a.k.a. SHA-0) and "RIPEMD" (the original version). This commit adds backward-compatibility support for the old Crypto.Hash.SHA and Crypto.Hash.RIPEMD modules.
* Hash: Rename SHA->SHA1 and RIPEMD->RIPEMD160 (1/2)Dwayne Litzenberger2013-02-163-5/+5
| | | | | | | | | These algorithm names were confusing, because there are actually algorithms called "SHA" (a.k.a. SHA-0) and "RIPEMD" (the original version). This commit just renames the modules, with no backward-compatibility support.
* Fix typos in docsDwayne C. Litzenberger2012-05-231-1/+1
|
* Added documentation for all hash algorithmsLegrandin2012-05-0512-255/+801
| | | | (including for HMAC which, strictly speaking, does not belong with them).
* Merged from upstream (py3k support) and modified so that all unit tests pass.Legrandin2011-10-1810-25/+33
|\
| * SHA224/384/512: Py3k compatibilityDwayne C. Litzenberger2011-10-103-9/+12
| |
| * Merge branch 'master' into py3kDwayne C. Litzenberger2011-10-105-1/+101
| |\ | | | | | | | | | | | | | | | Conflicts: setup.py src/_fastmath.c
| * | PY3K _fastmath supportThorsten Behrens2010-12-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o _fastmath now builds and runs on PY3K o Changes to setup.py to allow /usr/include for gmp.h o Changes to setup.py to allow linking fastmath w/ static mpir on Windows without warning messages o Changes to test_DSA/test_RSA to throw an exception if _fastmath is present but cannot be imported (due to an issue building _fastmath or the shared gmp/mpir libraries not being reachable) o number.py has the code to flag a failing _fastmath, but that code is commented out for a better runtime experience o Clean up the if for py21compat import - should have been == not is o Clean up some '== None' occurences, now 'is None' instead
| * | Changes to allow pycrpyto to work on Python 3.x as well as 2.1 through 2.7Thorsten Behrens2010-12-283-10/+13
| | |
* | | Added Lorenz Quack's native C implementation of all SHA-2 algorithmLegrandin2011-10-168-13/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | (as submitted here https://bugs.launchpad.net/pycrypto/+bug/544792) so that they are available also in Python 2.1, 2.2, 2.3 and 2.4. Regardless where the implementation comes from (Python standard library or our native modules, depending on the Python version), all Crypto.Hash objects are always used as front-ends.
* | | Merged with upstream.Legrandin2011-09-205-1/+163
|\ \ \ | | |/ | |/|
| * | Add variable block size support to HMAC-SHA384 and HMAC-SHA512 which useFrédéric Bertolus2011-04-085-4/+11
| | | | | | | | | | | | block of 128 bytes long
| * | Add SHA224, SHA384 and SHA512 hash algorithm.Frédéric Bertolus2011-04-083-0/+93
| |/
* | Simplify wrapper, as digest_size is known in advance each time.Legrandin2011-02-072-6/+6
| |
* | Fixed typoLegrandin2011-02-061-1/+1
| |
* | First fully tested version of Crypto.Signature.PKCS1_PSSLegrandin2011-02-062-0/+2
| |
* | Add OID to each hash algorithm.Legrandin2011-02-032-14/+38
|/
* Remove dead RIPEMD160.py implementation (we already have a C implementation)Dwayne C. Litzenberger2010-08-021-259/+0
|
* HMAC.py: Add clarified copyright noticeDwayne C. Litzenberger2009-08-021-0/+33
|
* Legal: Add PD dedication to __init__.py files and hash stubsDwayne C. Litzenberger2009-03-014-0/+78
| | | | | | | | From what I can tell, the authors of these files are: - Andrew Kuchling (who has dedicated his contributions to the public domain); and/or - Dwayne Litzenberger (myself).
* Legal: Dedicate my files to the public domain.Dwayne C. Litzenberger2009-03-011-20/+17
| | | | | | | | | | | | | In an attempt to simplify the copyright status of PyCrypto, I'm placing my code into the public domain, and encouraging other contributors to do the same. I have used a public domain dedication that was recommended in a book on FOSS legal issues[1], followed by the warranty disclaimer boilerplate from the MIT license. [1] _Intellectual Property and Open Source: A Practical Guide to Protecting Code_, a book written by Van Lindberg and published by O'Reilly Media. (ISBN 978-0-596-51796-0)
* cleanup: Move modules to "lib/Crypto" subdirectory.Dwayne C. Litzenberger2009-02-286-0/+438
This will avoid the previous situation where scripts like the old "test.py" get included accidentally in a release. It also frees us to put additional build scripts in the top-level directory of the source tree.
View Lorry Controller Status