| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the PyCrypto 2.6.1 release.
Dwayne Litzenberger (4):
Random: Make Crypto.Random.atfork() set last_reseed=None (CVE-2013-1445)
Fortuna: Add comments for reseed_interval and min_pool_size to FortunaAccumulator
Update the ChangeLog
Release v2.6.1
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
== Summary ==
In PyCrypto before v2.6.1, the Crypto.Random pseudo-random number
generator (PRNG) exhibits a race condition that may cause it to generate
the same 'random' output in multiple processes that are forked from each
other. Depending on the application, this could reveal sensitive
information or cryptographic keys to remote attackers.
An application may be affected if, within 100 milliseconds, it performs
the following steps (which may be summarized as "read-fork-read-read"):
1. Read from the Crypto.Random PRNG, causing an internal reseed;
2. Fork the process and invoke Crypto.Random.atfork() in the child;
3. Read from the Crypto.Random PRNG again, in at least two different
processes (parent and child, or multiple children).
Only applications that invoke Crypto.Random.atfork() and perform the
above steps are affected by this issue. Other applications are
unaffected.
Note: Some PyCrypto functions, such as key generation and PKCS#1-related
functions, implicitly read from the Crypto.Random PRNG.
== Technical details ==
Crypto.Random uses Fortuna[1] to generate random numbers. The flow of
entropy looks something like this:
/dev/urandom -\
+-> "accumulator" --> "generator" --> output
other sources -/ (entropy pools) (AES-CTR)
- The "accumulator" maintains several pools that collect entropy from
the environment.
- The "generator" is a deterministic PRNG that is reseeded by the
accumulator. Reseeding normally occurs during each request for random
numbers, but never more than once every 100 ms (the "minimum reseed
interval").
When a process is forked, the parent's state is duplicated in the child.
In order to continue using the PRNG, the child process must invoke
Crypto.Random.atfork(), which collects new entropy from /dev/urandom and
adds it to the accumulator. When new PRNG output is subsequently
requested, some of the new entropy in the accumulator is used to reseed
the generator, causing the output of the child to diverge from its
parent.
However, in previous versions of PyCrypto, Crypto.Random.atfork() did
not explicitly reset the child's rate-limiter, so if the child requested
PRNG output before the minimum reseed interval of 100 ms had elapsed, it
would generate its output using state inherited from its parent.
This created a race condition between the parent process and its forked
children that could cause them to produce identical PRNG output for the
duration of the 100 ms minimum reseed interval.
== Demonstration ==
Here is some sample code that illustrates the problem:
from binascii import hexlify
import multiprocessing, pprint, time
import Crypto.Random
def task_main(arg):
a = Crypto.Random.get_random_bytes(8)
time.sleep(0.1)
b = Crypto.Random.get_random_bytes(8)
rdy, ack = arg
rdy.set()
ack.wait()
return "%s,%s" % (hexlify(a).decode(),
hexlify(b).decode())
n_procs = 4
manager = multiprocessing.Manager()
rdys = [manager.Event() for i in range(n_procs)]
acks = [manager.Event() for i in range(n_procs)]
Crypto.Random.get_random_bytes(1)
pool = multiprocessing.Pool(processes=n_procs,
initializer=Crypto.Random.atfork)
res_async = pool.map_async(task_main, zip(rdys, acks))
pool.close()
[rdy.wait() for rdy in rdys]
[ack.set() for ack in acks]
res = res_async.get()
pprint.pprint(sorted(res))
pool.join()
The output should be random, but it looked like this:
['c607803ae01aa8c0,2e4de6457a304b34',
'c607803ae01aa8c0,af80d08942b4c987',
'c607803ae01aa8c0,b0e4c0853de927c4',
'c607803ae01aa8c0,f0362585b3fceba4']
== Solution ==
The solution is to upgrade to PyCrypto v2.6.1 or later, which properly
resets the rate-limiter when Crypto.Random.atfork() is invoked in the
child.
== References ==
[1] N. Ferguson and B. Schneier, _Practical Cryptography_,
Indianapolis: Wiley, 2003, pp. 155-184.
|
| |/
|
|
|
|
| |
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.
|
| |\ |
|
| | |
| |
| |
| |
| | |
- Use absolute imports
- Fix StringIO import so that 2to3 can translate it
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Doing the wraping later, at the point of use instead.
|
| | |
| |
| |
| |
| | |
o Random selftest is improved, less likely to collide
o random.shuffle() is more pythonic
|
| | |
| |
| |
| | |
Patch as per Lorenz on the mailing list.
|
| | |
| |
| |
| |
| |
| | |
o Add unit tests
o Fix random.shuffle()
o random.sample() does not work on 2.1. This has not been fixed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
(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.
|
| |
|
|
| |
during self-test is normal
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This should allow people to use something like this if they want
backwards-compatibility:
try:
from Crypto.Random import get_random_bytes
except ImportError:
try:
from os import urandom as get_random_bytes
except ImportError:
get_random_bytes = open("/dev/urandom", "rb").read
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RandomPoolCompat seems to give people the wrong idea that it's okay to use
RandomPool if Crypto.Random is not available.
try:
from Crypto.Random import RandomPoolCompat as RandomPool
except ImportError:
from Crypto.Util.randpool import RandomPool
In order to discourage all use of RandomPool, I'm getting rid of
RandomPoolCompat. Instead, Crypto.Util.randpool.RandomPool will be a wrapper
around Crypto.Random that emits a DeprecationWarning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
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.
|
