summaryrefslogtreecommitdiff
path: root/lib/Crypto/Hash
Commit message (Collapse)AuthorAgeFilesLines
* 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