Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #7146 > unrolled thread

Re: How good is security via hashing

Started byRobin Becker <robin@reportlab.com>
First post2011-06-07 12:35 +0100
Last post2011-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.


Contents

  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

#7146 — Re: How good is security via hashing

FromRobin Becker <robin@reportlab.com>
Date2011-06-07 12:35 +0100
SubjectRe: 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]


#7148

FromJean-Paul Calderone <calderone.jeanpaul@gmail.com>
Date2011-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]


#7150

FromRobin Becker <robin@reportlab.com>
Date2011-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