Am 08.06.2011 11:13 schrieb Robin Becker:
we have been using base62 ie 0-9A-Za-z just to reduce the name length.
Ugly concerning calculation. Then maybe better use radix32 - 0..9a..v,
case-insensitive.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
On 07/06/2011 21:42, Paul Rubin wrote:
geremy condra writes:
# adds random junk to the filename- should make it hard to guess
rrr = os.urandom(16)
fname += base64.b64encode(rrr)
Don't use b64 output in a filename -- it can have slashes in it! :-(
Simplest is to use old fashioned hexadeimal
Nobody writes:
>>> If you're going to read from /dev/urandom, limit it to a few bytes per
>>> minute, not per request.
>> That's really not going to help you.
> In what way?
> If I need security, I'll use /dev/random or /dev/urandom. If I don't, I'll
> save the real entropy for something which nee
On Tue, 07 Jun 2011 19:38:29 -0700, Paul Rubin wrote:
>> Personally, I'd take whatever "cheap" entropy I can get and hash it.
>> If you're going to read from /dev/urandom, limit it to a few bytes per
>> minute, not per request.
>
> That's really not going to help you.
In what way?
If I need sec
On Tue, Jun 7, 2011 at 7:30 PM, Paul Rubin wrote:
> Christian Heimes writes:
>> PyCrypto has a strong pseudorandom number generator, too.
>
> If you mean the one at pycrypto.org, that page now says:
>
> Random number generation
>
> Do not use RandomPool to generate random numbers. Use Crypt
Nobody writes:
> The problem with /dev/urandom is that it shares the same entropy pool as
> /dev/random, so you're "stealing" entropy which may be needed for tasks
> which really need it (e.g. generating SSL/TLS keys).
The most thorough analysis of Linux's /dev/*random that I know of is
here:
Christian Heimes writes:
> PyCrypto has a strong pseudorandom number generator, too.
If you mean the one at pycrypto.org, that page now says:
Random number generation
Do not use RandomPool to generate random numbers. Use Crypto.Random
instead. RandomPool is deprecated and will be re
Am 07.06.2011 20:26, schrieb Terry Reedy:
> On 6/7/2011 7:35 AM, Robin Becker wrote:
>
>> 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.
>
> Apparently so. random.random is *not* 'cryptographically secu
On Tue, Jun 7, 2011 at 1:42 PM, Paul Rubin wrote:
> geremy condra writes:
>> # adds random junk to the filename- should make it hard to guess
>> rrr = os.urandom(16)
>> fname += base64.b64encode(rrr)
>
> Don't use b64 output in a filename -- it can have slashes in it! :-(
>
> Simplest is to use
On Tue, 07 Jun 2011 13:27:59 +0100, Robin Becker wrote:
>> If you want the full 16 bytes of unpredictability, why don't you just
>> read 16 bytes from
>> /dev/urandom and forget about all the other stuff?
>
> I have a vague memory that the original author felt that entropy might
> run out or somet
On Tue, Jun 7, 2011 at 2:42 PM, Paul Rubin wrote:
> geremy condra writes:
>> # adds random junk to the filename- should make it hard to guess
>> rrr = os.urandom(16)
>> fname += base64.b64encode(rrr)
>
> Don't use b64 output in a filename -- it can have slashes in it! :-(
>
> Simplest is to use
geremy condra writes:
> # adds random junk to the filename- should make it hard to guess
> rrr = os.urandom(16)
> fname += base64.b64encode(rrr)
Don't use b64 output in a filename -- it can have slashes in it! :-(
Simplest is to use old fashioned hexadeimal for stuff like that, unless
the numbe
On Tue, Jun 7, 2011 at 3:18 AM, Robin Becker wrote:
> A python web process is producing files that are given randomized names of
> the form
>
> hh-MMDDhhmmss-.pdf
>
> where rrr.. is a 128bit random number (encoded as base62). The intent of the
> random part is to prevent recipients
On 6/7/2011 7:35 AM, Robin Becker wrote:
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.
Apparently so. random.random is *not* 'cryptographically secure'.
https://secure.wikimedia.org/wikipedia/en/wiki/C
Robin Becker writes:
> I have a vague memory that the original author felt that entropy might
> run out or something like that so reading from /dev/urandom always was
> not a good idea.
If there is enough entropy to begin with, then /dev/urandom should be
cryptographically strong. The main dange
On 07/06/2011 12:40, Jean-Paul Calderone wrote:
astcgi and the
initialization is only carried out once and then say 50 rrr values are
generated.
How much randomness do you actually have in this scheme? The PID is
probably difficult
for an attacker to know, but it's allocated roughly monotonic
/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
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 7, 7:35 am, Robin Becker 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-an
On Jun 7, 6:18 am, Robin Becker wrote:
> A python web process is producing files that are given randomized names of
> the form
>
> hh-MMDDhhmmss-.pdf
>
> where rrr.. is a 128bit random number (encoded as base62). The intent of the
> random part is to prevent recipients of one file
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
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
On Tue, Jun 7, 2011 at 3:48 PM, Robin Becker wrote:
> A python web
A python web process is producing files that are given randomized names of the
form
hh-MMDDhhmmss-.pdf
where rrr.. is a 128bit random number (encoded as base62). The intent of the
random part is to prevent recipients of one file from being able to guess the
names of others.
22 matches
Mail list logo
