Am Donnerstag, 12. September 2013, 14:47:23 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:35 PM, Stephan Mueller
wrote:
>>>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
>>>
>>>
>> wrote:
>>>>>BTW, I prefer a different
Am Donnerstag, 12. September 2013, 14:15:35 schrieb Geert Uytterhoeven:
Hi Geert,
>On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
wrote:
>>>BTW, I prefer a different name than "random_get_fast_cycles()", as
>>>it's better to have something that returns di
Am Donnerstag, 12. September 2013, 13:59:04 schrieb Geert Uytterhoeven:
Hi Geert,
>On Wed, Sep 11, 2013 at 8:49 AM, Stephan Mueller
wrote:
>> __u64 tmp = random_get_fast_cycles() - random_get_fast_cycles();
>> if(0 == tmp)
>>
>> return fail;
>>
>
Am Dienstag, 10. September 2013, 17:14:54 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Sep 10, 2013 at 10:48:00PM +0200, Geert Uytterhoeven wrote:
>> So the first importance for random_get_fast_cycles() is that it needs
>> to be fast. What's most important next: number of bits or
>> high-frequenc
Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:
Hi John,
>On Tue, Sep 10, 2013 at 4:31 AM, Stephan Mueller
wrote:
>> Hi,
>>
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and the event value of hardware e
Am Dienstag, 10. September 2013, 14:25:24 schrieb Theodore Ts'o:
Hi Theodore,
>
>Also note that the clocksource is not necessarily be the best choice;
>it may not be the most fine grained sampling that we have available
>(that is certainly be true for MIPS). So doing something hacky
>doesn't abs
Am Dienstag, 10. September 2013, 11:04:19 schrieb Theodore Ts'o:
Hi Theodore,
>On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
>> Hi,
>>
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and th
call to get_cycles on an x86_64 system to verify
that clocksource delivers data.
Ciao
Stephan
Signed-off-by: Stephan Mueller
---
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0d91fe5..d2d14a1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -255,6 +255,7
Am Sonntag, 18. August 2013, 20:05:52 schrieb Stephan Mueller:
Hi Ted, Sandy,
For FIPS 140-2, there is currently a draft of an Implementation Guidance
discussed covering the requirements of seed sources for deterministic
random number generators. The standard seed source when having no
Hi Sandy, Ted,
(this is a reply to [3])
I prepared a new release of the CPU Jitter RNG available at [1]. The
core of the RNG remains unchanged. However, there are the following
changes:
- addition of a patch to integrate the RNG into /dev/random as explained
in appendix B.3 of [2], although t
Am Dienstag, 21. Mai 2013, 17:39:49 schrieb Sandy Harris:
Hi Sandy, Ted,
I prepared a new release of the CPU Jitter RNG available at [1]. The
core of the RNG remains unchanged. However, there are the following
changes:
- addition of a patch to integrate the RNG into /dev/random as explained
i
y-base.c, jitterentropy.h and jitterentropy-base-kernel.h
from the tarball available at http://www.chronox.de.
This patch would only use the CPU Jitter RNG if there is no more
entropy in the entropy pool. Thus, the CPU Jitter RNG is only used as a
fallback.
The patch is tested with 3.9.
Si
On Wed, 22 May 2013 13:40:04 -0400
Sandy Harris wrote:
Hi Sandy,
> Stephan Mueller wrote:
>
> > Ted is right that the non-deterministic behavior is caused by the OS
> > due to its complexity. ...
>
> >> > For VM's, it means we should definitel
On Tue, 21 May 2013 17:39:49 -0400
Sandy Harris wrote:
Hi Sandy,
> On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote:
>
> > I continue to be suspicious about claims that userspace timing
> > measurements are measuring anything other than OS behaviour.
>
> Yes, but they do seem to contain s
On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris wrote:
Hi Sandy,
> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor
documentation are available at the
web site as well.
Note: for the kernel crypto API, please read the provided Kconfig file
for the switches and which of them are recommended in regular
operation. These switches must currently be set manually in the
Makefile.
Ciao
Stephan
Signed-off-by: Stephan Mueller
the
web site as well.
Note: for the kernel crypto API, please read the provided Kconfig file
for the provided switches and which of them are recommended in regular
operation. These switches must currently be set manually in the
Makefile.
Ciao
Stephan
Signed-off-by: Stephan Mueller
--
To
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
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
&
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
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
On 06.02.2013 17:15:57, +0100, Kyle McMartin wrote:
Hi Kyle,
> On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote:
>> On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
>>
>> Hi Kyle,
>>
>
> Thanks for the review, Stephan.
>
>> Just re
On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote:
Hi Kyle,
> fips mode needs to prevent unsigned modules from registering crypto
> algorithms, and currently panics if an unsigned module is attempted to
> be loaded. Instead, forbid (by returning -EINVAL) registering a crypto
> alg or template i
.
Signed-off-by: Stephan Mueller
--- Kconfig.orig2013-01-25 13:42:54.649705380 +0100
+++ Kconfig 2013-01-25 13:43:16.737705712 +0100
@@ -22,11 +22,11 @@
comment "Crypto core or helper"
config CRYPTO_FIPS
- bool "FIPS 200 compliance"
+ bool &q
far too polite. This patch was horrible, partial and ugly.
Well, in another email I suggested you may want to think about some
marker that the code of the module would contain, similar to the GPL
flag for the module (whose absence sets the tainted flag).
>
> Stephan Mueller wrote:
>> FIPS
On 25.01.2013 04:20:07, +0100, Matthew Garrett wrote:
Hi Matthew,
> On Fri, Jan 25, 2013 at 12:14:54AM +, David Howells wrote:
>
>> You can't rely on someone trying to sneak a dodgy crypto module in to set the
>> flag when they build it. The detection thus needs to be done in the kernel
>>
On 24.01.2013 20:06:10, +0100, Kyle McMartin wrote:
Hi Kyle,
> After thinking about it a while, this seems like the best way to solve
> the problem, although it does still kind of offend my delicate
> sensibilities...
>
> Doing this check in the crypto layer seems kind of like a layering
> viola
On 24.01.2013 15:59:07, +0100, Kyle McMartin wrote:
Hi Kyle,
> On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote:
>> 3. in the cipher initialization code of the crypto API (i.e. the one
>> behind crypto_register_alg()), you check the signature check flag --
>>
which need to deny module loading such as secure boot already set
>> sig_enforce, so there's no issue here.
>>
>> Reported-by: Jan Stancek
>> Signed-off-by: Kyle McMartin
>
> Fine by me, but adding Stephan Mueller for his input.
FIPS requires the module (in our case
On 13.12.2012 08:44:36, +0100, Stephan Mueller wrote:
Hi Andrew,
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> wrote:
>
> Hi Andrew,
>> On Tue, 11 Dec 2012 13:33:04 +0100
>> Stephan Mueller wrote:
>>
>>> Some time ago, I noticed the fact that fo
On 13.12.2012 01:43:21, +0100, Andrew Morton
wrote:
Hi Andrew,
> On Tue, 11 Dec 2012 13:33:04 +0100
> Stephan Mueller wrote:
>
>> Some time ago, I noticed the fact that for every newly
>> executed process, the function create_elf_tables requests 16 bytes of
>> rando
On 11.12.2012 13:33:04, +0100, Stephan Mueller wrote:
Hi,
I just noticed a misuse of a variable in my initial patch
> + if (r->limit == 2 && r->entropy_count >= r->poolinfo->poolwords)
Instead of r->entropy_count, the code should use entropy_count.
Please se
nks
Stephan
Signed-off-by: Stephan Mueller
---
diff -purN linux-3.6/drivers/char/random.c linux-3.6-sm/drivers/char/random.c
--- linux-3.6/drivers/char/random.c 2012-10-01 01:47:46.0 +0200
+++ linux-3.6-sm/drivers/char/random.c 2012-12-11 11:51:58.997172447 +0100
@@ -404,11 +404
On 14.11.2012 18:52:53, +0100, H. Peter Anvin wrote:
Hi Peter,
> On 11/14/2012 08:15 AM, Stephan Mueller wrote:
>>
>> I agree with the argument of correlation.
>>
>> So, if the reduction of values with a known lack of entropy is of
>> interest, why not cha
On 08.11.2012 12:47:08, +0100, Theodore Ts'o wrote:
Hi Theodore,
> On Thu, Nov 08, 2012 at 01:32:38AM +0100, Stephan Mueller wrote:
>>
>> However, due to the fact that jiffies provides very few entropy, the
>> event value provides (almost) none, the majority of
Hi,
the function add_timer_randomness currently defines:
struct {
...
unsigned cycles;
...
} sample;
Cycles used to be of type cycles_t. The inline get_cycles that fills
cycles is still of type cycles_t.
Unsigned is 32 bit whereas get_cycles is 64 bit. This means
27;s some
> indication that the crypto stuff is compromised, the box should be shut down
> immediately.
>
> I've added Stephan Mueller to see if he can illuminate further.
>
> David
>
The requirement for a FIPS 140-2 module is to disable the entire module
if any comp
901 - 938 of 938 matches
Mail list logo
