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

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

How good is security via hashing

Back to article view | Back to comp.lang.python

Contents

  How good is security via hashing Robin Becker <robin@reportlab.com> - 2011-06-07 11:18 +0100
    Re: How good is security via hashing Jean-Paul Calderone <calderone.jeanpaul@gmail.com> - 2011-06-07 04:40 -0700
      Re: How good is security via hashing Robin Becker <robin@reportlab.com> - 2011-06-07 13:27 +0100
        Re: How good is security via hashing Paul Rubin <no.email@nospam.invalid> - 2011-06-07 06:00 -0700
        Re: How good is security via hashing Nobody <nobody@nowhere.com> - 2011-06-07 22:23 +0100
          Re: How good is security via hashing Paul Rubin <no.email@nospam.invalid> - 2011-06-07 19:38 -0700
            Re: How good is security via hashing Nobody <nobody@nowhere.com> - 2011-06-08 08:18 +0100
              Re: How good is security via hashing Paul Rubin <no.email@nospam.invalid> - 2011-06-08 00:40 -0700

#7145 — How good is security via hashing

A python web process is producing files that are given randomized names of the form

hhhhhh-YYYYMMDDhhmmss-rrrrrrrr.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.

The process was originally a cgi script which meant each random number was 
produced thusly


pid is process id, dur is 4 bytes from /dev/urandom.

random.seed(long(time.time()*someprimeint)|(pid<<64)|(dur<<32))
rrr = random.getrandbits(128)


is this algorithm safe? Is it safe if the process is switched to fastcgi and the 
initialization is only carried out once and then say 50 rrr values are generated.
-- 
Robin Becker

[toc] | [next] | [standalone]

#7147

On Jun 7, 6:18 am, Robin Becker <ro...@reportlab.com> wrote:
> A python web process is producing files that are given randomized names of the form
>
> hhhhhh-YYYYMMDDhhmmss-rrrrrrrr.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.
>
> The process was originally a cgi script which meant each random number was
> produced thusly
>
> pid is process id, dur is 4 bytes from /dev/urandom.
>
> random.seed(long(time.time()*someprimeint)|(pid<<64)|(dur<<32))
> rrr = random.getrandbits(128)
>
> is this algorithm safe? Is it safe if the process is switched to fastcgi 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 monotonically with
a known
wrap-around value.  The time is probably roughly known, so it also
contributes less
than its full bits to the randomness.  Only dur is really
unpredictable.  So you have
something somewhat above 4 bytes of randomness in your seed - perhaps
8 or 10.  That's
much less than even the fairly small 16 bytes of "randomness" you
expose in the
filename.

The random module is entirely deterministic, so once the seed is known
the value you
produce is known too.

Is 10 bytes enough to thwart your attackers?  Hard to say, what does
an attack look like?

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?

Jean-Paul

[toc] | [prev] | [next] | [standalone]

#7152

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 monotonically with
> a known
> wrap-around value.  The time is probably roughly known, so it also
> contributes less
> than its full bits to the randomness.  Only dur is really
> unpredictable.  So you have
> something somewhat above 4 bytes of randomness in your seed - perhaps
> 8 or 10.  That's
> much less than even the fairly small 16 bytes of "randomness" you
> expose in the
> filename.

I'm sure you're right about the limited amount of entropy in the initial state, 
but how much state can be in the prng?

>
> The random module is entirely deterministic, so once the seed is known
> the value you
> produce is known too.
>
> Is 10 bytes enough to thwart your attackers?  Hard to say, what does
> an attack look like?
An attacker could try to gain information from seeing others' results by 
guessing the filename.

an attack would consist of generating a sample file via a web query which might 
take 1 or 2 seconds; the sequence number could then be seen and if the state 
established future filenames could be guessed if fastcgi is in operation.

In a cgi type scheme that requires searching over the pid space, the time space 
and some random bits from the OS.

I'm not sure such an attack is realistic given the size of the space even in the 
initial seed.

>
> 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?
>
> Jean-Paul
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.

FreeBSD re-uses the entropy, but the end target is Solaris so I'm not really 
sure about the details of /dev/urandom.
-- 
Robin Becker

[toc] | [prev] | [next] | [standalone]

#7154

Robin Becker <robin@reportlab.com> 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 danger is just after the system
boots and there has not yet been much entropy gathered from physical
events.

> FreeBSD re-uses the entropy, but the end target is Solaris so I'm not
> really sure about the details of /dev/urandom.

No idea about Solaris.  Another area of danger these days is virtual
hosts, since their I/O may be completely simulated.  They are not
certified for payment card processing, mostly for that reason.

[toc] | [prev] | [next] | [standalone]

#7187

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 something like that so reading from /dev/urandom always was
> not a good idea.

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).

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.

[toc] | [prev] | [next] | [standalone]

#7207

Nobody <nobody@nowhere.com> 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:

   http://www.pinkas.net/PAPERS/gpr06.pdf 

It says random and urandom use separate pools, though both fed from the
same primary pool.  The point is that reading from one should not
interfere with the other.

There have been interminable threads on sci.crypt about /dev/random vs
/dev/urandom and the sane conclusion seems to be that if there's enough
entropy in the system, /dev/urandom is not really worse than
/dev/random.  Any type of userspace randomness collection is probably
worse than either.  If you're doing typical low-to-medium security stuff
on traditional PC hardware (i.e. not virtualized, not something like
OpenWRT which has few real entropy sources), /dev/urandom is fine.  If
you don't believe in its cryptographic PRNG, you shouldn't believe in
OpenSSL either.

If you're doing high security stuff (server-side financial apps, etc.)
then /dev/urandom and /dev/random are both considered not good enough,
and your PC is probably leaking keys, so you should be using dedicated
crypto hardware.

> 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.

[toc] | [prev] | [next] | [standalone]

#7216

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 security, I'll use /dev/random or /dev/urandom. If I don't, I'll
save the real entropy for something which needs it.

Issues with observability of entropy sources (mainly the use of network
traffic as an entropy source) are overblown. The staff of a co-location
facility have physical access, and anyone further out doesn't see enough
of the traffic for it to do them any good.

Predicting an entropy-hashing RNG based upon a fraction of the entropy
and a fraction of the output is a theoretical attack which is only
relevant to entities who have far easier options available to them.

[toc] | [prev] | [next] | [standalone]

#7220

Nobody <nobody@nowhere.com> 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 needs it.

I just mean that if /dev/urandom has enough internal state then within
practical bounds, its output is effectively random no matter how much
you read from it.  Did you look at the paper I linked?  "Saving" the
"real entropy" isn't feasible since the maximum capacity of the two
"real" entropy pools is 4096 bits each.  They will both fill pretty
quickly on an active system.  Reading /dev/urandom will empty the
primary pool but /dev/random is fed by the secondary pool, which
receives entropy from both the primary pool and physical sources.  If
you read too fast from /dev/urandom, the worst that happens (if I
understand correctly) is that the rate you can read from /dev/random is
cut in half and it will block more often.  If that's a serious issue for
your application, you should probably rethink your approach and get an
HSM.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web