Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #7146 > unrolled thread
| Started by | Robin Becker <robin@reportlab.com> |
|---|---|
| First post | 2011-06-07 12:35 +0100 |
| Last post | 2011-06-07 13:07 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: How good is security via hashing Robin Becker <robin@reportlab.com> - 2011-06-07 12:35 +0100
Re: How good is security via hashing Jean-Paul Calderone <calderone.jeanpaul@gmail.com> - 2011-06-07 04:42 -0700
Re: How good is security via hashing Robin Becker <robin@reportlab.com> - 2011-06-07 13:07 +0100
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Date | 2011-06-07 12:35 +0100 |
| Subject | Re: How good is security via hashing |
| Message-ID | <mailman.2526.1307446540.9059.python-list@python.org> |
On 07/06/2011 11:26, Nitin Pawar wrote: > Have you tried using UUID module? > > Its pretty handy and comes with base64 encoding function which gives > extremely high quality randon strings > > ref: > http://stackoverflow.com/questions/621649/python-and-random-keys-of-21-char-max ...... I didn't actually ask for a suitable method for doing this; I assumed that Tim Peters' algorithm (at least I think he's behind most of the python random support) is pretty good so that the bits produced are indeed fairly good approximations to random. I guess what I'm asking is whether any sequence that's using random to generate random numbers is predictable if enough samples are drawn. In this case assuming that fastcgi is being used can I observe a sequence of generated numbers and work out the state of the generator. If that is possible then the sequence becomes deterministic and such a scheme is useless. If I use cgi then we're re-initializing the sequence hopefully using some other unrelated randomness for each number. Uuid apparently uses machine internals etc etc to try and produce randomness, but urandom and similar can block so are probably not entirely suitable. -- Robin Becker
[toc] | [next] | [standalone]
| From | Jean-Paul Calderone <calderone.jeanpaul@gmail.com> |
|---|---|
| Date | 2011-06-07 04:42 -0700 |
| Message-ID | <b5f3c287-d3d4-4de4-b094-779dcdf073da@u26g2000vby.googlegroups.com> |
| In reply to | #7146 |
On Jun 7, 7:35 am, Robin Becker <ro...@reportlab.com> wrote: > On 07/06/2011 11:26, Nitin Pawar wrote:> Have you tried using UUID module? > > > Its pretty handy and comes with base64 encoding function which gives > > extremely high quality randon strings > > > ref: > >http://stackoverflow.com/questions/621649/python-and-random-keys-of-2... > > ...... > I didn't actually ask for a suitable method for doing this; I assumed that Tim > Peters' algorithm (at least I think he's behind most of the python random > support) is pretty good so that the bits produced are indeed fairly good > approximations to random. > > I guess what I'm asking is whether any sequence that's using random to generate > random numbers is predictable if enough samples are drawn. In this case assuming > that fastcgi is being used can I observe a sequence of generated numbers and > work out the state of the generator. If that is possible then the sequence > becomes deterministic and such a scheme is useless. If I use cgi then we're > re-initializing the sequence hopefully using some other unrelated randomness for > each number. > > Uuid apparently uses machine internals etc etc to try and produce randomness, > but urandom and similar can block so are probably not entirely suitable. /dev/urandom does not block, that's the point of it as compared to / dev/random. Jean-Paul
[toc] | [prev] | [next] | [standalone]
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Date | 2011-06-07 13:07 +0100 |
| Message-ID | <mailman.2527.1307448458.9059.python-list@python.org> |
| In reply to | #7148 |
........ > > /dev/urandom does not block, that's the point of it as compared to / > dev/random. > > Jean-Paul my mistake, I thought it was the other way round, on FreeBSD they're the same anyway which is what we test on. -- Robin Becker
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web