| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
The solution is to include Python.h before string.h is included.
|
| |
|
|
|
|
| |
Oops, I missed this one.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Hopefully this means we'll break on fewer platforms.
Also, remove some of the extra optimization flags (e.g. -O3
-fomit-frame-pointer), which don't really do much.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
random.shuffle("1") is a no-op, so it doesn't raise TypeError. This is
now true of both the stdlib random.shuffle and PyCrypto's random.shuffle
implementation.
|
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation took O(n**2) time and O(n) auxiliary space.
We now use the Fisher-Yates algorithm, which takes O(n) time and O(1)
space.
Thanks to Sujay Jayakar and Andrew Cooke for pointing this out and
suggesting a solution.
Bug report: https://bugs.launchpad.net/pycrypto/+bug/1061217
|
|
|
|
|
|
|
| |
Fix leaks in getRandomInteger and rsaKeyNew. If randfunc throws an exception
they both don't clean up properly.
Thanks to Andreas Stührk for helping me to debug these two leaks.
|
| |
|
| |
|
|
|
|
|
| |
On my machine, hashlib is about 5x faster than PyCrypto for single-block
inputs. :( (It's about the same for long inputs.)
|
| |
|
| |
|
|
|
|
| |
They don't have os.urandom, so use Crypto.Random.get_random_bytes
|
| |
|
|
|
|
|
|
| |
Exporting symbols can cause symbol conflicts with external libraries,
causing the dynamic linker to silently pick one of the implementations,
which can lead to subtle bugs if they're actually different functions.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
... and run the sub_commands in TestCommand.run. So if python setup.py test is
executed before ever running the build target, the extension modules are built.
Bug: https://bugs.launchpad.net/pycrypto/+bug/1055256
Bug: https://bugs.launchpad.net/pycrypto/+bug/976171
|
|
|
|
| |
versions of Python
|
|\
| |
| |
| | |
Pull request: https://github.com/dlitz/pycrypto/pull/19
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ECB mode has known disadvantages and while the use of it could be
intended, I think it would be a good idea to have a 'stronger' mode in
the example.
Thus, I adopted the example in the README to make use of MODE_CBC
instead of MODE_ECB.
|
| | |
|
| |
| |
| |
| |
| | |
"long int" is equivalent to "long" in C, and it's harder to misread it as
"int" this way.
|
| |
| |
| |
| | |
This should never happen, but the behaviour is saner if it does.
|
| | |
|
|\ \ |
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
Pull request: https://github.com/dlitz/pycrypto/pull/23
|
| | | |
| | | |
| | | |
| | | |
| | | | |
rabinMillerTest returns an int but getStrongPrime stores the result in an
unsigned long int which makes the tests in line 1545 and 1621 useless.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
Affects isPrime and getStrongPrime.
See https://github.com/dlitz/pycrypto/pull/23 ("Store result of
rabinMillerTest in an int.") for the bug report.
|
|/ /
| |
| |
| | |
is available.
|
| | |
|
| |
| |
| |
| |
| | |
Test vectors are taken from RFC 6229.
All tests pass.
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
The example code contained special character '\x00' that is directly
shown by epydoc.
Counter module was not included in __init__ of Crypto.Util
|
|\ |
|