Am Donnerstag, 14. November 2013, 19:30:22 schrieb Clemens Ladisch:
Hi Clemens,
>Stephan Mueller wrote:
>> Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
>>> An attacker would not try to detect patterns; he would apply
>>> knowledge
>>> of the internals.
>>
>> I do not buy
Stephan Mueller wrote:
> Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
>> An attacker would not try to detect patterns; he would apply knowledge
>> of the internals.
>
> I do not buy that argument, because if an attacker can detect or deduce
> the internals of the CPU, he
Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
Hi Clemens,
>Stephan Mueller wrote:
>> Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
>>> (And any setting that increases accesses to main memory is likey to
>>> introduce more entropy due to clock drift
Stephan Mueller wrote:
> Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
>> (And any setting that increases accesses to main memory is likey to
>> introduce more entropy due to clock drift between the processor and the
>> memory bus. Or where do you assume the entropy comes
Stephan Mueller wrote:
Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
(And any setting that increases accesses to main memory is likey to
introduce more entropy due to clock drift between the processor and the
memory bus. Or where do you assume the entropy comes from?)
Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
(And any setting that increases accesses to main memory is likey to
introduce more entropy due to clock drift between the
Stephan Mueller wrote:
Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
An attacker would not try to detect patterns; he would apply knowledge
of the internals.
I do not buy that argument, because if an attacker can detect or deduce
the internals of the CPU, he surely can
Am Donnerstag, 14. November 2013, 19:30:22 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
An attacker would not try to detect patterns; he would apply
knowledge
of the internals.
I do not buy that argument,
Hi!
> >BTW: MFENCE is not guaranteed to flush the instruction pipeline; you
> >need CPUID for that.
>
> I was not aware of that. Can I simply call the CPUID instruction to read
> it or do I have to do something special?
Simply call CPUID (warning, it clobbers some registers.).
Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
Hi Clemens,
>Stephan Mueller wrote:
>> Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
>>> Many CPUs allow to disable branch prediction, but this is very
>>> vendor
>>> specific (try to find MSR documentation).
Stephan Mueller wrote:
> Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
>> Many CPUs allow to disable branch prediction, but this is very vendor
>> specific (try to find MSR documentation). The biggest offender probably
>> is the out-of-order execution engine, which cannot be
Stephan Mueller wrote:
Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
Many CPUs allow to disable branch prediction, but this is very vendor
specific (try to find MSR documentation). The biggest offender probably
is the out-of-order execution engine, which cannot be disabled.
Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
Many CPUs allow to disable branch prediction, but this is very
vendor
specific (try to find MSR documentation). The biggest
Hi!
BTW: MFENCE is not guaranteed to flush the instruction pipeline; you
need CPUID for that.
I was not aware of that. Can I simply call the CPUID instruction to read
it or do I have to do something special?
Simply call CPUID (warning, it clobbers some registers.).
Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
Hi Clemens,
> Stephan Mueller wrote:
> > Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
> >> In the case of CPUs, the jitter you observe in delta
> >> times results in part from the complexities of the inner
Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
In the case of CPUs, the jitter you observe in delta
times results in part from the complexities of the inner state, and in
On 11/10/2013 09:21 AM, Stephan Mueller wrote:
>
> Here you say it: we *assume*. And please bear in mind that we all know for a
> fact that the theory behind quantum physics is not complete, because it does
> not work together with the theory of relativity. That again is a hint that
> there is
Stephan Mueller wrote:
> Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
>> In the case of CPUs, the jitter you observe in delta
>> times results in part from the complexities of the inner state, and in
>> part from real random noise. The first part is deterministic and might
>>
Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
Hi Clemens,
> Stephan Mueller wrote:
> > Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
> >> Stephan Mueller wrote:
> >>> Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
> On Wed, Nov 06, 2013
Stephan Mueller wrote:
> Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
>> Stephan Mueller wrote:
>>> Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
>> That's unfortunate, since it leaves
Stephan Mueller wrote:
Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question
Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
On Wed, Nov 06, 2013 at 01:51:17PM
Stephan Mueller wrote:
Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
In the case of CPUs, the jitter you observe in delta
times results in part from the complexities of the inner state, and in
part from real random noise. The first part is deterministic and might
be
On 11/10/2013 09:21 AM, Stephan Mueller wrote:
Here you say it: we *assume*. And please bear in mind that we all know for a
fact that the theory behind quantum physics is not complete, because it does
not work together with the theory of relativity. That again is a hint that
there is NO
Am Samstag, 9. November 2013, 23:04:07 schrieb Clemens Ladisch:
Hi Clemens,
> Stephan Mueller wrote:
> > Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
> >> On Wed, 06 Nov 2013, Stephan Mueller wrote:
> >>> Besides, how on earth shall an attacker even gain knowledge about
Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
Hi Clemens,
> Stephan Mueller wrote:
> > Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
> >> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
> That's unfortunate, since it leaves open the
Stephan Mueller wrote:
> Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
>> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of whether this
jitter is something that could be at least somewhat
Stephan Mueller wrote:
> Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
>> On Wed, 06 Nov 2013, Stephan Mueller wrote:
>>> Besides, how on earth shall an attacker even gain knowledge about the
>>> state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA
>>> guy. But
Stephan Mueller wrote:
Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
On Wed, 06 Nov 2013, Stephan Mueller wrote:
Besides, how on earth shall an attacker even gain knowledge about the
state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA
guy. But if he is
Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of whether this
jitter is something that could be at least somewhat predictable if you
Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of
Am Samstag, 9. November 2013, 23:04:07 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
On Wed, 06 Nov 2013, Stephan Mueller wrote:
Besides, how on earth shall an attacker even gain knowledge about the
state
Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
Hi Nicholas,
>On Wed, 06 Nov 2013, Stephan Mueller wrote:
>> Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
>>
>> Hi Theodore,
>>
>> >On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
>> >> Here
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
Hi Theodore,
>On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
>> >That's unfortunate, since it leaves open the question of whether
>> >this
>> >jitter is something that could be at least somewhat predictable if
>>
Am Mittwoch, 6. November 2013, 14:26:35 schrieb Pavel Machek:
Hi Pavel,
>Hi!
>
>> >I plugged that idea into my current Jitter RNG processing and
>> >disabled
>> >the other jitter measurements to get a clear, isolated picture.
>> >
>> >The result is also a white noise! And it is even quite fast.
On Wed, 06 Nov 2013, Stephan Mueller wrote:
> Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
>
> Hi Theodore,
>
> >On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
> >> Here is a quote from his answer to my question whether he was able to
> >> identify the root
On Wed, 06 Nov 2013, Pavel Machek wrote:
> Hi!
>
> > Of course, some of the state in the CPU may not be unknown to the
> > attacker, if it is derived by external events that are not visible to
> > the attacker, such as a network interrupt. But if that's the case,
> > why not measure network
Hi!
> >I plugged that idea into my current Jitter RNG processing and disabled
> >the other jitter measurements to get a clear, isolated picture.
> >
> >The result is also a white noise! And it is even quite fast.
>
> After doing some more research on this approach, I have to admit that
> the
Hi!
> Of course, some of the state in the CPU may not be unknown to the
> attacker, if it is derived by external events that are not visible to
> the attacker, such as a network interrupt. But if that's the case,
> why not measure network interrupts directly? We're much less likely
> to
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
> >That's unfortunate, since it leaves open the question of whether this
> >jitter is something that could be at least somewhat predictable if you
> >had a lot more information about the internal works of the CPU or
> >not
>
> I
Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
Hi Theodore,
>On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
>> Here is a quote from his answer to my question whether he was able to
>> identify the root cause:
>>
>> "its inherent in the microtiming of Hardware
On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
> Here is a quote from his answer to my question whether he was able to
> identify the root cause:
>
> "its inherent in the microtiming of Hardware and there is nothing you
> can do about it if you want the root cause is quantum
Am Dienstag, 5. November 2013, 13:20:57 schrieb Stephan Mueller:
Hi Ted,
>Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o:
>
>Hi Theodore,
>
>>On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
>>
>>Sandy Harris pointed out a very good paper that I would definitely
Am Dienstag, 5. November 2013, 14:45:58 schrieb Stephan Mueller:
Hi Pavel,
>Am Dienstag, 5. November 2013, 13:25:40 schrieb Stephan Mueller:
>
>Hi Pavel,
>
>>Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
>>>But they usually _do_ have RTC or other clock, not driven by CPU
Am Dienstag, 5. November 2013, 14:45:58 schrieb Stephan Mueller:
Hi Pavel,
Am Dienstag, 5. November 2013, 13:25:40 schrieb Stephan Mueller:
Hi Pavel,
Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
But they usually _do_ have RTC or other clock, not driven by CPU
oscilator. Good.
Am Dienstag, 5. November 2013, 13:20:57 schrieb Stephan Mueller:
Hi Ted,
Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o:
Hi Theodore,
On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
Sandy Harris pointed out a very good paper that I would definitely
recommend
On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
Here is a quote from his answer to my question whether he was able to
identify the root cause:
its inherent in the microtiming of Hardware and there is nothing you
can do about it if you want the root cause is quantum physics
Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
Hi Theodore,
On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
Here is a quote from his answer to my question whether he was able to
identify the root cause:
its inherent in the microtiming of Hardware and there
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of whether this
jitter is something that could be at least somewhat predictable if you
had a lot more information about the internal works of the CPU or
not
I do not
Hi!
Of course, some of the state in the CPU may not be unknown to the
attacker, if it is derived by external events that are not visible to
the attacker, such as a network interrupt. But if that's the case,
why not measure network interrupts directly? We're much less likely
to overestimate
Hi!
I plugged that idea into my current Jitter RNG processing and disabled
the other jitter measurements to get a clear, isolated picture.
The result is also a white noise! And it is even quite fast.
After doing some more research on this approach, I have to admit that
the output not
On Wed, 06 Nov 2013, Pavel Machek wrote:
Hi!
Of course, some of the state in the CPU may not be unknown to the
attacker, if it is derived by external events that are not visible to
the attacker, such as a network interrupt. But if that's the case,
why not measure network interrupts
On Wed, 06 Nov 2013, Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
Hi Theodore,
On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
Here is a quote from his answer to my question whether he was able to
identify the root cause:
Am Mittwoch, 6. November 2013, 14:26:35 schrieb Pavel Machek:
Hi Pavel,
Hi!
I plugged that idea into my current Jitter RNG processing and
disabled
the other jitter measurements to get a clear, isolated picture.
The result is also a white noise! And it is even quite fast.
After doing
Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
Hi Theodore,
On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of whether
this
jitter is something that could be at least somewhat predictable if
you
had a lot
Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
Hi Nicholas,
On Wed, 06 Nov 2013, Stephan Mueller wrote:
Am Mittwoch, 6. November 2013, 07:43:54 schrieb Theodore Ts'o:
Hi Theodore,
On Wed, Nov 06, 2013 at 12:49:45PM +0100, Stephan Mueller wrote:
Here is a quote from
Am Dienstag, 5. November 2013, 13:25:40 schrieb Stephan Mueller:
Hi Pavel,
>Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
>>But they usually _do_ have RTC or other clock, not driven by CPU
>>oscilator. Good.
>>
>>What about just
>>
>>while (!enough_entropy) {
>>
>> cur_time =
Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
Hi Pavel,
>Hi!
>
>> Another friend of mine mentioned that he assumes the rise and fall
>> times of transistors varies very slightly and could be the main
>> reason for the jitter. I do not think that this is really the case,
>> because
Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o:
Hi Theodore,
>On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
>
>Sandy Harris pointed out a very good paper that I would definitely
>recommend that people read:
>
Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o:
Hi Theodore,
On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
Sandy Harris pointed out a very good paper that I would definitely
recommend that people read:
http://lwn.net/images/conf/rtlws11/random-hardware.pdf
It
Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
Hi Pavel,
Hi!
Another friend of mine mentioned that he assumes the rise and fall
times of transistors varies very slightly and could be the main
reason for the jitter. I do not think that this is really the case,
because our gates
Am Dienstag, 5. November 2013, 13:25:40 schrieb Stephan Mueller:
Hi Pavel,
Am Montag, 4. November 2013, 00:32:07 schrieb Pavel Machek:
But they usually _do_ have RTC or other clock, not driven by CPU
oscilator. Good.
What about just
while (!enough_entropy) {
cur_time = read_rtc();
Hi!
> Another friend of mine mentioned that he assumes the rise and fall times
> of transistors varies very slightly and could be the main reason for the
> jitter. I do not think that this is really the case, because our gates
> that form the CPU instructions comprise of many transistors. The
On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
> Another friend of mine mentioned that he assumes the rise and fall times
> of transistors varies very slightly and could be the main reason for the
> jitter. I do not think that this is really the case, because our gates
> that
Am Samstag, 2. November 2013, 12:01:13 schrieb Pavel Machek:
Hi Pavel,
>Hi!
>
>> >sense of where the unpredictability might be coming from, and
>> >whether
>> >the unpredictability is coming from something which is fundamentally
>> >arising from something which is chaotic or quantum effect, or
Am Samstag, 2. November 2013, 12:01:13 schrieb Pavel Machek:
Hi Pavel,
Hi!
sense of where the unpredictability might be coming from, and
whether
the unpredictability is coming from something which is fundamentally
arising from something which is chaotic or quantum effect, or just
because
On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
Another friend of mine mentioned that he assumes the rise and fall times
of transistors varies very slightly and could be the main reason for the
jitter. I do not think that this is really the case, because our gates
that form
Hi!
Another friend of mine mentioned that he assumes the rise and fall times
of transistors varies very slightly and could be the main reason for the
jitter. I do not think that this is really the case, because our gates
that form the CPU instructions comprise of many transistors. The
On Sat 2013-11-02 12:01:12, Pavel Machek wrote:
> Hi!
>
> > >sense of where the unpredictability might be coming from, and whether
> > >the unpredictability is coming from something which is fundamentally
> > >arising from something which is chaotic or quantum effect, or just
> > >because we
Hi!
> >sense of where the unpredictability might be coming from, and whether
> >the unpredictability is coming from something which is fundamentally
> >arising from something which is chaotic or quantum effect, or just
> >because we don't have a good way of modelling the behavior of the
> >L1/L2
Hi!
sense of where the unpredictability might be coming from, and whether
the unpredictability is coming from something which is fundamentally
arising from something which is chaotic or quantum effect, or just
because we don't have a good way of modelling the behavior of the
L1/L2 cache (for
On Sat 2013-11-02 12:01:12, Pavel Machek wrote:
Hi!
sense of where the unpredictability might be coming from, and whether
the unpredictability is coming from something which is fundamentally
arising from something which is chaotic or quantum effect, or just
because we don't have a good
Theodore Ts'o wrote:
> Fundamentally, what worries me about this scheme (actually, causes the
> hair on the back of my neck to rise up on end) is this statement in
> your documentation[1]:
>
>When looking at the sequence of time deltas gathered
>during testing [D] , no pattern can be
Theodore Ts'o ty...@mit.edu wrote:
Fundamentally, what worries me about this scheme (actually, causes the
hair on the back of my neck to rise up on end) is this statement in
your documentation[1]:
When looking at the sequence of time deltas gathered
during testing [D] , no pattern can
Am Dienstag, 29. Oktober 2013, 15:00:31 schrieb Stephan Mueller:
Hi Ted,
>Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
>
>Hi Theodore,
>
>>On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
>>> Based on this suggestion, I now added the tests in Appendix F.46.8
>>>
Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
>> Based on this suggestion, I now added the tests in Appendix F.46.8
>> where I disable the caches and the tests in Appendix F.46.9 where I
>> disable
On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
> Based on this suggestion, I now added the tests in Appendix F.46.8 where
> I disable the caches and the tests in Appendix F.46.9 where I disable
> the caches and interrupts.
What you've added in F.46 is a good start, but as a
Am Montag, 28. Oktober 2013, 17:45:49 schrieb Theodore Ts'o:
Hi Theodore,
first of all, thank you for your thoughts.
And, before we continue any discussion, please consider that all the big
testing that is done to analyze the jitter so far did (a) not include
any whitening schema
Am Montag, 28. Oktober 2013, 17:45:49 schrieb Theodore Ts'o:
Hi Theodore,
first of all, thank you for your thoughts.
And, before we continue any discussion, please consider that all the big
testing that is done to analyze the jitter so far did (a) not include
any whitening schema
On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
Based on this suggestion, I now added the tests in Appendix F.46.8 where
I disable the caches and the tests in Appendix F.46.9 where I disable
the caches and interrupts.
What you've added in F.46 is a good start, but as a
Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
Hi Theodore,
On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
Based on this suggestion, I now added the tests in Appendix F.46.8
where I disable the caches and the tests in Appendix F.46.9 where I
disable the
Am Dienstag, 29. Oktober 2013, 15:00:31 schrieb Stephan Mueller:
Hi Ted,
Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
Hi Theodore,
On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
Based on this suggestion, I now added the tests in Appendix F.46.8
where I
Fundamentally, what worries me about this scheme (actually, causes the
hair on the back of my neck to rise up on end) is this statement in
your documentation[1]:
When looking at the sequence of time deltas gathered
during testing [D] , no pattern can be detected. Therefore, the
Am Montag, 28. Oktober 2013, 14:06:23 schrieb Henrique de Moraes
Holschuh:
Hi Henrique,
>On Mon, 28 Oct 2013, Stephan Mueller wrote:
>> If it is accepted that the CPU Jitter RNG delivers entropy, the
>> latter
>> update may now allow us to get rid of storing the seed file during
>> shutdown and
On Mon, 28 Oct 2013, Stephan Mueller wrote:
> If it is accepted that the CPU Jitter RNG delivers entropy, the latter
> update may now allow us to get rid of storing the seed file during
> shutdown and restoring it during the next boot sequence.
That's a 4096-bit safety net (uncredited entropy)
Am Freitag, 11. Oktober 2013, 20:38:51 schrieb Stephan Mueller:
Hi Ted,
>Hi,
>
>the CPU Jitter RNG [1] is a true random number generator that is
>intended to work in user and kernel space equally well on a large
>number of different CPUs. The heart of the RNG is about 30 lines of
>code. The
Am Freitag, 11. Oktober 2013, 20:38:51 schrieb Stephan Mueller:
Hi Ted,
Hi,
the CPU Jitter RNG [1] is a true random number generator that is
intended to work in user and kernel space equally well on a large
number of different CPUs. The heart of the RNG is about 30 lines of
code. The current
On Mon, 28 Oct 2013, Stephan Mueller wrote:
If it is accepted that the CPU Jitter RNG delivers entropy, the latter
update may now allow us to get rid of storing the seed file during
shutdown and restoring it during the next boot sequence.
That's a 4096-bit safety net (uncredited entropy)
Am Montag, 28. Oktober 2013, 14:06:23 schrieb Henrique de Moraes
Holschuh:
Hi Henrique,
On Mon, 28 Oct 2013, Stephan Mueller wrote:
If it is accepted that the CPU Jitter RNG delivers entropy, the
latter
update may now allow us to get rid of storing the seed file during
shutdown and
Fundamentally, what worries me about this scheme (actually, causes the
hair on the back of my neck to rise up on end) is this statement in
your documentation[1]:
When looking at the sequence of time deltas gathered
during testing [D] , no pattern can be detected. Therefore, the
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
Could you please review the following code to see that the mix is
function right in your eyes?
>
>However, having done that, I see no reason not to add mixing.
>Using bit() for getting one bit of input and rotl(x) for
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
Could you please review the following code to see that the mix is
function right in your eyes?
However, having done that, I see no reason not to add mixing.
Using bit() for getting one bit of input and rotl(x) for rotating
Stephan Mueller wrote:
> [quoting me]
>> ...your code is basically, with 64-bit x:
>>
>> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) )
>>x |= bit()
>
> Why not declare some 64-bit constant C with a significant
>>number of bits set and do this:
>>
>> for( i=0, x = 0 ; i < 64; i++, x
On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller wrote:
>>Why not declare some 64-bit constant C with a significant
>
> Which constant would you take? The CRC twist values? The SHA-1 initial
> values? Or the first few from SHA-256?
The only essential requirement is that it not be something
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
>On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller
wrote:
>> Another thing: when you start adding whitening functions, other
>> people
>> are starting (and did -- thus I added section 4.3 to my
>> documentation)
>> to
On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller wrote:
> Another thing: when you start adding whitening functions, other people
> are starting (and did -- thus I added section 4.3 to my documentation)
> to complain that you hide your weaknesses behind the whiteners. I simply
> want to counter
Am Montag, 14. Oktober 2013, 10:14:00 schrieb Sandy Harris:
Hi Sandy,
>On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris
wrote:
>> Stephan Mueller wrote:
>>> Can you please help me understand why you think that a whitening
>>> function (cryptographic or not) is needed in the case of the CPU
>>>
Am Montag, 14. Oktober 2013, 16:12:24 schrieb Stephan Mueller:
Hi Sandy,
>
>(PS: I am aware that in case none of the individual bits would contain
>one full bit of entropy, the folding operation may --mathematically
>spoken-- not deliver one full bit of entropy. However, after speaking
>with a
On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris wrote:
> Stephan Mueller wrote:
>> Can you please help me understand why you think that a whitening
>> function (cryptographic or not) is needed in the case of the CPU Jitter
>> RNG, provided that I can show that each individual bit coming from the
Am Montag, 14. Oktober 2013, 09:38:34 schrieb Sandy Harris:
Hi Sandy,
>Stephan Mueller wrote:
>
>>>If what you are doing is not a parity computation, then you need a
>>>better description so people like me do not misread it.
>>>
>> It is not a parity computation that the folding loop performs.
1 - 100 of 120 matches
Mail list logo