Discovery: Concurrency problems might be used to create ps..

On Sun, 23 Dec 2007 00:58:06 +0100, "Skybuck Flying"
<spam.DeleteThis@hotmail.com> wrote:

>Your wish has been forfilled.

Google 'forfilled' produces "Did you mean: fulfilled"

>I had some time and wrote some code.
>
>See the new thread called:
>
>"Skybuck's Racing Random Number Generator"

Excellent...

--
Z
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Dec 20, 10:43 pm, "Skybuck Flying" <s... RemoveThis @hotmail.com> wrote:
> How so ?
>
> Different instructions have different latencies.
>
> Multiple threads executing all kinds of weird maybe even useless
> instructions might end-up getting slightly different ammounts of time slices
> etc...
>
> This could create difficult to predict random numbers ?
>
> In other words, given enough instructions threads will not execute perfectly
> in sync, but different...

Threads don't execute in sync, but their execution offsets will tend
to vary according to predictable patterns.

> Bye,
> Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Sat, 1 Dec 2007 21:35:31 +0100
"Skybuck Flying" <spam.DeleteThis@hotmail.com> wrote:

> Just create multiple threads/instances let them execute some
> instructions...

Besides the comments of the other posters, you can get much better
randomness with much less overhead, so why bother?


Regards,
Ertugrul Söylemez.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

>> Just create multiple threads/instances let them execute some
>> instructions...

> Besides the comments of the other posters, you can get much better
> randomness with much less overhead, so why bother?

Ok, I'll bite:

How ?

Bye,
Skybuck
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Mon, 11 Feb 2008 15:05:23 +0100
"Skybuck Flying" <spam.DeleteThis@hotmail.com> wrote:

> >> Just create multiple threads/instances let them execute some
> >> instructions...
> >
> > Besides the comments of the other posters, you can get much better
> > randomness with much less overhead, so why bother?
>
> Ok, I'll bite:
>
> How ?

By using well established methods. By gathering entropy from sources,
which are much more random than parallel execution drift. I/O, human
interaction, environmental noise, etc.


Regards,
Ertugrul Söylemez.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

>> >> Just create multiple threads/instances let them execute some
>> >> instructions...
>> >
>> > Besides the comments of the other posters, you can get much better
>> > randomness with much less overhead, so why bother?
>>
>> Ok, I'll bite:
>>
>> How ?

>By using well established methods. By gathering entropy from sources,
>which are much more random than parallel execution drift. I/O, human
>interaction, environmental noise, etc.

Human interaction, i/o is already included in the parallel execution drift.

Each time harddisks, mouse, or whatever is used or invoked (by the user or
otherwise) it affects the threading and the rest of the machine.

So I would consider those inputs already represented in the "parallel drift"
as you call it

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Mon, 11 Feb 2008 16:28:13 +0100
"Skybuck Flying" <spam.DeleteThis@hotmail.com> wrote:

> >>>> Just create multiple threads/instances let them execute some
> >>>> instructions...
> >>>
> >>> Besides the comments of the other posters, you can get much better
> >>> randomness with much less overhead, so why bother?
> >>
> >> Ok, I'll bite:
> >>
> >> How ?
> >
> > By using well established methods. By gathering entropy from
> > sources, which are much more random than parallel execution drift.
> > I/O, human interaction, environmental noise, etc.
>
> Human interaction, i/o is already included in the parallel execution
> drift.
>
> Each time harddisks, mouse, or whatever is used or invoked (by the
> user or otherwise) it affects the threading and the rest of the
> machine.
>
> So I would consider those inputs already represented in the "parallel
> drift" as you call it

Yes, with minimal to zero impact. Even a keystroke can impact the PRNG
state a lot. Considering the granularity of current timer chips and the
typing rate of the average user, and the granularity with which an
attacker can measure/estimate the exact time of the stroke, each stroke
adds at least about 10 bits of randomness, if you mix the system time
into the pool at each stroke.

With your method, how much entropy is added by a keystroke? Likely none
at all, because a key stroke produces little overhead. It wouldn't
impact your thread pair noticably.

In traditional methods, not only the fact that I/O is being done, and
the length and overhead are used as entropy, but also the nature and
some other data about the I/O are used. With your method, you waste a
lot of potential entropy.

If your view is different, go ahead and provide a proof of concept. And
even if you manage to show that your method does actually generate a few
entropy bits per hour (which it certainly does), then why should one
want to prefer your method? It wastes system resources -- all the time.


Regards,
Ertugrul Söylemez.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Ertugrul Söylemez wrote:
> On Mon, 11 Feb 2008 16:28:13 +0100
> "Skybuck Flying" <spam.DeleteThis@hotmail.com> wrote:
>
>>>>>> Just create multiple threads/instances let them execute some
>>>>>> instructions...
>>>>> Besides the comments of the other posters, you can get much better
>>>>> randomness with much less overhead, so why bother?
>>>> Ok, I'll bite:
>>>>
>>>> How ?
>>> By using well established methods. By gathering entropy from
>>> sources, which are much more random than parallel execution drift.
>>> I/O, human interaction, environmental noise, etc.
>> Human interaction, i/o is already included in the parallel execution
>> drift.
>>
>> Each time harddisks, mouse, or whatever is used or invoked (by the
>> user or otherwise) it affects the threading and the rest of the
>> machine.
>>
>> So I would consider those inputs already represented in the "parallel
>> drift" as you call it
>
> Yes, with minimal to zero impact. Even a keystroke can impact the PRNG
> state a lot. Considering the granularity of current timer chips and the
> typing rate of the average user, and the granularity with which an
> attacker can measure/estimate the exact time of the stroke, each stroke
> adds at least about 10 bits of randomness, if you mix the system time
> into the pool at each stroke.

This estimate seems very high.


>
> With your method, how much entropy is added by a keystroke? Likely none
> at all, because a key stroke produces little overhead. It wouldn't
> impact your thread pair noticably.
>
> In traditional methods, not only the fact that I/O is being done, and
> the length and overhead are used as entropy, but also the nature and
> some other data about the I/O are used. With your method, you waste a
> lot of potential entropy.
>
> If your view is different, go ahead and provide a proof of concept. And
> even if you manage to show that your method does actually generate a few
> entropy bits per hour (which it certainly does), then why should one
> want to prefer your method? It wastes system resources -- all the time.
>
>
> Regards,
> Ertugrul Söylemez.
>
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Tue, 12 Feb 2008 10:25:11 +1000
David Eather <eather.TakeThisOut@tpg.com.au> wrote:

> > Yes, with minimal to zero impact. Even a keystroke can impact the
> > PRNG state a lot. Considering the granularity of current timer
> > chips and the typing rate of the average user, and the granularity
> > with which an attacker can measure/estimate the exact time of the
> > stroke, each stroke adds at least about 10 bits of randomness, if
> > you mix the system time into the pool at each stroke.
>
> This estimate seems very high.

Well, again consider that current timer chips have a very high
granularity up to microseconds. I don't expect any attacker (without
the ability to manipulate the keyboard or OS) to be able to estimate the
exact time of a key press any more precisely than to milliseconds. That
makes 10 bits pretty reasonable.

Maybe I've missed something? What do you think? But even if I did, and
even if this method adds only a single bit per key stroke, I'd still
consider it a better entropy source, because it's random, while
Skybuck's method is highly predictable.


Regards,
Ertugrul Söylemez.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

So far I have seen no proof that it was predictable.

Check out the latest version which has the bug fixes.

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

On Tue, 12 Feb 2008 19:47:41 +0100
"Skybuck Flying" <spam RemoveThis @hotmail.com> wrote:

> So far I have seen no proof that it was predictable.
>
> Check out the latest version which has the bug fixes.

Yes, because Usenet just isn't an appropriate place for specifications.
Unless you write a paper about your method, including analysis, simply
nobody is going to be interested seriously. So nobody feels like
analyzing your little elaboration any more than telling you that it
wouldn't be useful in real-world scenarious anyway, even if it would
provide a reasonable amount of entropy.


Regards,
Ertugrul Söylemez.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps.. 

Lol, excuses.

Bye,
Skybuck.
 >> Stay informed about: Discovery: Concurrency problems might be used to create ps..