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 t
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 sure
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 betwee
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?
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). Th
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 dis
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,
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
>> b
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
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
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 th
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 questio
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 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
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
>> >yo
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 ca
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 inte
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 out
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 overesti
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 an
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 ph
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
>>re
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
>>>oscilato
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 o
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.pd
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 f
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 ju
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
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 c
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 dete
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 the
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 sug
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 (cryptographi
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
fluctuatio
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) w
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 curre
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 =ro
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 stup
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 complai
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 t
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
>>> Ji
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 Freitag, 11. Oktober 2013, 21:45:57 schrieb Sandy Harris:
Hi Sandy,
>On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller
>wrote:
>
>I like the basic idea. Here I'm alternately reading the email and the
>page you link to & commenting on both.
Thank you very much for reviewing both and sharing yo
Am Freitag, 11. Oktober 2013, 23:28:35 schrieb Theodore Ts'o:
Hi Theodore,
>Hi Stephan,
>
>I haven't had a chance to look at your paper in detail, yet, but a
>quick scan has found a huge red flag for me that puts the rest of your
>analysis in severe doubt for me.
>
>You say that you got really go
Hi Stephan,
I haven't had a chance to look at your paper in detail, yet, but a
quick scan has found a huge red flag for me that puts the rest of your
analysis in severe doubt for me.
You say that you got really good results and perfect statistical
entropy on a number of platforms, including on an
On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller wrote:
I like the basic idea. Here I'm alternately reading the email and the
page you link to & commenting on both.
A nitpick in the paper is that you cite RFC 1750. That was superceded
some years back by RFC 4086
http://tools.ietf.org/html/rfc408
56 matches
Mail list logo
