I'm so sorry, something went terribly wrong with gmail/thunderbird :-(
2013/2/22 Nick Kossifidis :
> Hello all,
>
> It's nice to see there is still discussion on the matter of using cpu
> timings for entropy. In general using cpu timings for gathering entropy is a
> nice idea but it's not that unp
On Thu, Feb 21, 2013 at 12:46:45PM -0500, Sandy Harris wrote:
>
> Also, in some designs it is possible to get very close to calculating
> entropy. The Turbid generator, for example, uses physical measurements
> of sound card properties plus arguments from standard circuit physics to
> prove a lowe
On Thu, Feb 21, 2013 at 9:17 AM, Stephan Mueller wrote:
> There is no state between calls. Of course, you need a scratchpad to do
> calculations.
But in general you need a buffer. It is quite easy to construct scenarios where
several K bits of entropy are needed very -- for example, reboot an IP
On 21.02.2013 15:07:12, +0100, Phil Carmody wrote:
Hi Phil,
> Apologies if this is misthreaded, I had to hand-craft the headers.
>
>> The patch offers an entropy generator based on CPU timing jitter. The
>> entropy collector has the following properties:
>>
>> * it does not maintain any state an
Apologies if this is misthreaded, I had to hand-craft the headers.
> The patch offers an entropy generator based on CPU timing jitter. The
> entropy collector has the following properties:
>
> * it does not maintain any state and therefore does not need any seed
What is this "pool" if it's not
On Sun, Feb 10, 2013 at 08:32:37PM +0100, Stephan Mueller wrote:
>
> Given all your doubts on the high-precision timer, how can you
> reasonably state that the Linux kernel RNG is good then?
Because we're measuring intervals that are substantially larger than
"CPU jitter". (i.e., inputs from key
On Sun, Feb 10, 2013 at 2:32 PM, Stephan Mueller wrote:
> On 10.02.2013 19:50:02, +0100, Theodore Ts'o wrote:
> Given all your doubts on the high-precision timer, how can you
> reasonably state that the Linux kernel RNG is good then?
>
> The data from add_timer_randomness the kernel feeds into
On 10.02.2013 19:50:02, +0100, Theodore Ts'o wrote:
Hi Ted,
> On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>> However, the CPU has timing jitter in the execution of instruction. And
>> I try to harvest that jitter. The good thing is that this jitter is
>> always present and ca
On Sun, Feb 10, 2013 at 1:50 PM, Theodore Ts'o wrote:
> On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>>
>> However, the CPU has timing jitter in the execution of instruction. And
>> I try to harvest that jitter. The good thing is that this jitter is
>> always present and can b
On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>
> However, the CPU has timing jitter in the execution of instruction. And
> I try to harvest that jitter. The good thing is that this jitter is
> always present and can be harvested on demand.
How do you know, though, that this is
OK, my original reading of the mixing code was not accurate. This time
around, I started with the original posted tarball and turned the use of
the CPU clock into a very simple and clearly bad "clock" that will
provide no entropy.
--- jitterentropy-0.1/jitterentropy.c 2013-02-08 15:22:22.0
On 10.02.2013 02:57:51, +0100, Jeff Epler wrote:
Hi Jeff,
> On Sat, Feb 09, 2013 at 01:06:29PM -0500, Theodore Ts'o wrote:
>> For that reasons, what I would suggest doing first is generate a
>> series of outputs of jitterentropy_get_nstime() followed by
>> schedule(). Look and see if there is an
On 09.02.2013 19:06:29, +0100, Theodore Ts'o wrote:
Hi Ted,
thank you for the review.
> On Fri, Feb 08, 2013 at 11:04:54PM +0100, Stephan Mueller wrote:
>> * an array of statistical test suites pass the output of the entropy
>> collector
>> (again, the output is not mangled with cryptography)
On Sat, Feb 09, 2013 at 01:06:29PM -0500, Theodore Ts'o wrote:
> For that reasons, what I would suggest doing first is generate a
> series of outputs of jitterentropy_get_nstime() followed by
> schedule(). Look and see if there is any pattern. That's the problem
> with the FIPS 140-2 tests. Pass
On Fri, Feb 08, 2013 at 11:04:54PM +0100, Stephan Mueller wrote:
> * an array of statistical test suites pass the output of the entropy
> collector
> (again, the output is not mangled with cryptography)
You're not mangling the output with cryptography, but you are doing
some mangling in jitteren
Hi crypto hackers,
[1] patch at http://www.chronox.de/jitterentropy-0.1.tar.gz
The Linux kernel RNG which we all use via /dev/random or /dev/urandom
received a lot of merits over the long years it exists. In particular
it was subject to countless researches and assessments and was determined
to d
16 matches
Mail list logo
