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,
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 state, and in
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
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 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 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();
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
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 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 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
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 rotating
Stephan Mueller smuel...@chronox.de wrote:
Paper has:
the time delta is partitioned into chunks of 1 bit starting at the
lowest bit The 64 1 bit chunks of the time value are XORed with
each other to form a 1 bit value.
As I read that, you are just taking the parity. Why not use that
Am Montag, 14. Oktober 2013, 09:38:34 schrieb Sandy Harris:
Hi Sandy,
Stephan Mueller smuel...@chronox.de 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
On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris sandyinch...@gmail.com wrote:
Stephan Mueller smuel...@chronox.de 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
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
Am Montag, 14. Oktober 2013, 10:14:00 schrieb Sandy Harris:
Hi Sandy,
On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris sandyinch...@gmail.com
wrote:
Stephan Mueller smuel...@chronox.de wrote:
Can you please help me understand why you think that a whitening
function (cryptographic or not) is
On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller smuel...@chronox.de 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
Am Montag, 14. Oktober 2013, 11:18:16 schrieb Sandy Harris:
Hi Sandy,
On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller smuel...@chronox.de
wrote:
Another thing: when you start adding whitening functions, other
people
are starting (and did -- thus I added section 4.3 to my
documentation)
On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller smuel...@chronox.de 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
Stephan Mueller smuel...@chronox.de 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
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 good
On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller smuel...@chronox.de 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
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
58 matches
Mail list logo
