Closed GoogleCodeExporter closed 9 years ago
Indeed I think os.urandom() would be a solid replacement at least on Linux. On
Linux it is a simple wrapper around /dev/urandom (I did read the code a while
ago). On Windows it seems to provide a wrapper around CryptGenRandom, I don't
know too much about it but seems to be the recommended PRNG and a valid choice
for generating secret keys.
Original comment by sebastien.martini
on 26 Jun 2010 at 9:40
I'm packaging python-keyczar for Debian. Should you produce a Linux-specific
solution on the way to a general one, please let me know and I'll include it as
a patch in the package.
Original comment by debian.k...@gmail.com
on 27 Jun 2010 at 1:57
I think os.urandom() will be a good replacement. Given the nature of the matter
it is in our best interest to be prudent, keep this code simple and generic
and go for a general solution.
Original comment by sebastien.martini
on 27 Jun 2010 at 2:16
Although I never was involved in design issues of keyczar I agree with
[http://code.google.com/u/sebastien.martini/ sebastien.martini] and believe
os.urandom could be of great use here.
In short:
* [http://www.google.pl/search?q=randpool-broken+python&aq=f&aqi=&aql=&oq=&gs_rfai= randpool-broken situation in general]
* [http://twistedmatrix.com/trac/ticket/4468 How twisted project approached that problem]
It might be also good idea to update the doc/pycrypt.tex - last update
2008-09-10 21:05:45.
The two possible diffs solve the deprecated waning issue one `using os.urandom`
second `Random.new`. The last remark regards that the current code uses 512
bytes range and none of the new solutions has that limit and makes all the test
pass without warnings.
Original comment by lukasz.m.dobrzanski
on 4 Jul 2010 at 1:02
Attachments:
Thanks for your help. The one with os.urandom() looks good to me. BTW, I think
we should also mention somewhere (maybe enforce it in setup.py) which versions
of Python are expected to work with Keyczar. I think right now Keyczar is
compatible with Python [2.4, 2.6].
Original comment by sebastien.martini
on 4 Jul 2010 at 3:19
FWIW, the underlying issue in PyCrypt has apparently been fixed, and the
deprecation notice is provided as a kind of warning for older applications
still using that interface:
http://gitweb.pycrypto.org/?p=crypto/pycrypto-2.x.git;a=commitdiff;h=4cf61f7ebbf
7a4985dac5115ae667967b3db0848
I haven't looked at all the changes in detail, but the new implementation +
interface might be worthwhile.
Also, they way I understand it, you're looking for os.random(), not
os.urandom(). Within keyczar, RandomPool is currently used to generate key
material; wit os.urandom(), an attacker could easily ensure predictable output
simply by starving the entropy pool.
Original comment by debian.k...@gmail.com
on 4 Jul 2010 at 6:11
Of course not, I'm only looking at something simple that reads from
/dev/urandom as does os.urandom(). os.urandom() seems a good choice as long as
we use Python >= 2.4. It is not implemented before, so we would either have to
require Python 2.4 or to use an alternative for Python < 2.4. Note that I'm not
even sure that the current Python Keyczar is still compatible with Python 2.3,
in this case problem solved. And I'm waiting the opinion of Steve on these
questions, he is currently unavailable.
Original comment by sebastien.martini
on 4 Jul 2010 at 6:36
Here is the commit http://code.google.com/p/keyczar/source/detail?r=473 it uses
os.urandom() as discussed before.
Original comment by sebastien.martini
on 23 Sep 2010 at 5:10
Original issue reported on code.google.com by
debian.k...@gmail.com
on 26 Jun 2010 at 6:26