wohaph / keyczar

Automatically exported from code.google.com/p/keyczar
0 stars 0 forks source link

python: RandomPool in PyCrypto is deprecated #59

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Run the cryptiterations.py testcase

What is the expected output? What do you see instead?

keyczar.utils uses Crypto.Util.randpool.RandomPool which has been deprecated as 
of PyCrypto-2.1alpha2. This causes a DeprecationWarning to be printed.

What version of the product are you using? On what operating system?

python-keyczar-0.6b.061709, on Debian sid.

Please provide any additional information below.

PyCrypto's homepage prominently points to this thread where the reasons for the 
deprecation are explained:
http://lists.dlitz.net/pipermail/pycrypto/2008q3/000000.html

Original issue reported on code.google.com by debian.k...@gmail.com on 26 Jun 2010 at 6:26

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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