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
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 component of its self test or integrity test failed.
In the kernel, we have the FIPS 140-2 module of the kernel crypto
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
On 09.02.2013 19:06:29, +0100, Theodore Ts'o ty...@mit.edu 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
On 10.02.2013 02:57:51, +0100, Jeff Epler jep...@unpythonic.net 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
On 10.02.2013 19:50:02, +0100, Theodore Ts'o ty...@mit.edu 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
On 05.02.2013 23:58:30, +0100, Kyle McMartin k...@redhat.com 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
On 06.02.2013 17:15:57, +0100, Kyle McMartin kmcma...@redhat.com 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 k...@redhat.com wrote:
Hi Kyle,
Thanks for the review, Stephan.
Just reading this paragraph
On 24.01.2013 15:59:07, +0100, Kyle McMartin kmcma...@redhat.com 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 --
panic
On 24.01.2013 20:06:10, +0100, Kyle McMartin k...@redhat.com 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
On 25.01.2013 04:20:07, +0100, Matthew Garrett mj...@srcf.ucam.org 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
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 stephan.muel...@atsec.com wrote
for
cryptography.
Signed-off-by: Stephan Mueller smuel...@chronox.de
--- 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
.
Reported-by: Jan Stancek jstan...@redhat.com
Signed-off-by: Kyle McMartin k...@redhat.com
Fine by me, but adding Stephan Mueller for his input.
FIPS requires the module (in our case the static kernel binary with its
kernel crypto API plus all the crypto kernel modules) to be unavailable
On 21.02.2013 15:07:12, +0100, Phil Carmody pc+l...@asdf.org 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
Stephan
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
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
On 11.12.2012 13:33:04, +0100, Stephan Mueller smuel...@chronox.de 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 see new patch attached
On 13.12.2012 01:43:21, +0100, Andrew Morton
a...@linux-foundation.org wrote:
Hi Andrew,
On Tue, 11 Dec 2012 13:33:04 +0100
Stephan Mueller smuel...@chronox.de wrote:
Some time ago, I noticed the fact that for every newly
executed process, the function create_elf_tables requests 16 bytes
On 13.12.2012 08:44:36, +0100, Stephan Mueller smuel...@chronox.de wrote:
Hi Andrew,
On 13.12.2012 01:43:21, +0100, Andrew Morton
a...@linux-foundation.org wrote:
Hi Andrew,
On Tue, 11 Dec 2012 13:33:04 +0100
Stephan Mueller smuel...@chronox.de wrote:
Some time ago, I noticed the fact
On 08.11.2012 12:47:08, +0100, Theodore Ts'o ty...@mit.edu 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 entropy comes from
On 14.11.2012 18:52:53, +0100, H. Peter Anvin h...@zytor.com 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 change the jiffies variable type too
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
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
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
call to get_cycles on an x86_64 system to verify
that clocksource delivers data.
Ciao
Stephan
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
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
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 the event value of hardware events.
Typically
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 absolve
Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:
Hi John,
On Tue, Sep 10, 2013 at 4:31 AM, Stephan Mueller smuel...@chronox.de
wrote:
Hi,
/dev/random uses the get_cycles() function to obtain entropy in
addition to jiffies and the event value of hardware events.
Typically
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-frequency?
Am Donnerstag, 12. September 2013, 13:59:04 schrieb Geert Uytterhoeven:
Hi Geert,
On Wed, Sep 11, 2013 at 8:49 AM, Stephan Mueller smuel...@chronox.de
wrote:
__u64 tmp = random_get_fast_cycles() - random_get_fast_cycles();
if(0 == tmp)
return fail;
return pass;
That will fail
Am Donnerstag, 12. September 2013, 14:15:35 schrieb Geert Uytterhoeven:
Hi Geert,
On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller smuel...@chronox.de
wrote:
BTW, I prefer a different name than random_get_fast_cycles(), as
it's better to have something that returns different and
unpredictable
Am Donnerstag, 12. September 2013, 14:47:23 schrieb Geert Uytterhoeven:
Hi Geert,
On Thu, Sep 12, 2013 at 2:35 PM, Stephan Mueller smuel...@chronox.de
wrote:
On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller
smuel...@chronox.de
wrote:
BTW, I prefer a different name than random_get_fast_cycles
Am Donnerstag, 12. September 2013, 17:31:48 schrieb Jörn Engel:
Hi Jörn,
On Tue, 10 September 2013 15:08:12 -0700, John Stultz wrote:
Though
I probably should be hesitant with my suggestions, as I'm not well
versed in RNG theory.
The basic principle of Ted's RNG is very simple and quite
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
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 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
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
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, 12:14:17 schrieb Jeff Liu:
Hi Jeff,
Hi Stephan,
As per your previous comments for this fix, you have promised another
approach which is promising to avoid entropy starvation, I got this
info from the following thread: [PATCH] avoid entropy starvation due
to
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 Freitag, 13. September 2013, 14:59:31 schrieb Theodore Ts'o:
Hi Theodore,
On Fri, Sep 13, 2013 at 07:36:20AM +0200, Stephan Mueller wrote:
However, if you are worried about a malicious entropy source, things
are a little bit different. Suppose RDRAND == AES(i++, NSA_KEY),
where the NSA
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 implementation allows seamless hooking into the kernel crypto
API as
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
Am Freitag, 11. Oktober 2013, 21:45:57 schrieb Sandy Harris:
Hi Sandy,
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.
Thank you very much for reviewing both
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
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
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
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
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
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
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 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
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
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
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
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
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
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/Makefile b/crypto/Makefile
index b29402a..0d63373 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
obj-$(CONFIG_CRYPTO_RNG2
://www.chronox.de/drbg.html
- Performing tests by obtaining data which is not a multiple of cipher block
size and check it with the ent tool to ensure that the generation loop
does not reuse stale buffers to avoid errors like CVE-2013-4345.
Signed-off-by: Stephan Mueller smuel
/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 7795550..baa6cb7 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/string.h
#include crypto/rng.h
+#include crypto
and backend cipher
* getter functions for data from struct drbg_core
Changes to v1:
* Changes due to modification of drbg.c as documented in PATCH 1
* Fix coding style and apply scripts/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
create mode 100644 include/crypto/drbg.h
diff
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled
at compile time. At least one DRBG type shall be selected.
The default is the HMAC DRBG as its code base is smallest.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index
of SHA-512.
Changes to v1:
* Fix coding style and apply scripts/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 7d44aa3..1f48312 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -92,6 +92,29 @@ struct
Hi,
As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of
this year for official uses, including FIPS 140-2 compliance.
I created a clean-room implementation of the DRBGs defined in SP800-90A,
specifically the Hash DRBG, HMAC DRBG and CTR DRBG. All three DRBGs are
Signed-off-by: Stephan Mueller smuel...@chronox.de
diff --git a/crypto/Makefile b/crypto/Makefile
index b29402a..0d63373 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
obj-$(CONFIG_CRYPTO_RNG2) += krng.o
.
As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of
this year for official uses, including FIPS 140-2 compliance.
Additional tests are available at [1].
[1] http://www.chronox.de/drbg.html
Stephan Mueller (6):
SP800-90A Deterministic Random Bit Generator
header file
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled
at compile time. At least one DRBG type shall be selected.
The default is the HMAC DRBG as its code base is smallest.
Signed-off-by: Stephan Mueller smuel...@chronox.de
diff --git a/crypto/Kconfig b/crypto/Kconfig
index
This is a clean-room implementation of the DRBG defined in SP800-90A.
All three viable DRBGs defined in the standard are implemented:
* HMAC
* Hash
* CTR
Signed-off-by: Stephan Mueller smuel...@chronox.de
create mode 100644 crypto/drbg.c
diff --git a/crypto/drbg.c b
cipher
* getter functions for data from struct drbg_core
Signed-off-by: Stephan Mueller smuel...@chronox.de
create mode 100644 include/crypto/drbg.h
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
new file mode 100644
index 000..16515f9
--- /dev/null
+++ b/include/crypto/drbg.h
of SHA-512.
Signed-off-by: Stephan Mueller smuel...@chronox.de
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 7d44aa3..2ee3bba 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -92,6 +92,29 @@ struct cprng_testvec {
unsigned short loops;
};
+struct drbg_testvec
not covered with specific test cases.
All currently implemented DRBG types and backend ciphers are definined
in SP800-90A. Therefore, the fips_allowed flag is set for all.
Signed-off-by: Stephan Mueller smuel...@chronox.de
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 7795550..e8cd57c
Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch:
Hi Clemens,
Rafael Aquini wrote:
This patch introduces changes to the random_write method so it can
split the given seed and completely stir the output pools with
different halves of it, when seed lenght allows us doing so.
-
Am Freitag, 10. Januar 2014, 12:37:26 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch:
Rafael Aquini wrote:
This patch introduces changes to the random_write method so it can
split the given seed and completely stir
Am Montag, 17. März 2014, 08:34:06 schrieb Stephan Mueller:
+static int drbg_seed(struct drbg_state *drbg, struct drbg_string *pers,
+ bool reseed)
+{
+ int ret = 0;
+ unsigned char *entropy = NULL;
+ size_t entropylen = 0;
+ struct drbg_string data1
Am Donnerstag, 20. März 2014, 09:12:55 schrieb Clemens Ladisch:
Hi Clemens,
Stephan Mueller wrote:
This is a clean-room implementation of the DRBG defined in SP800-90A.
Why? I guess it's for certification?
As per SP800-131A, the ANSI X9.31 DRNG is sunset by the end of 2014
the 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 smuel
On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris sandyinch...@gmail.com 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 (
On Tue, 21 May 2013 17:39:49 -0400
Sandy Harris sandyinch...@gmail.com wrote:
Hi Sandy,
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o ty...@mit.edu wrote:
I continue to be suspicious about claims that userspace timing
measurements are measuring anything other than OS behaviour.
Yes,
On Wed, 22 May 2013 13:40:04 -0400
Sandy Harris sandyinch...@gmail.com wrote:
Hi Sandy,
Stephan Mueller smuel...@chronox.de 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 definitely use
used as a
fallback.
The patch is tested with 3.9.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff -urNp linux-3.9.orig/drivers/char/Makefile linux-3.9/drivers/char/Makefile
--- linux-3.9.orig/drivers/char/Makefile2013-05-22 20:55:58.547094987
+0200
+++ linux-3.9/drivers/char
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 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
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 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
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
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
at 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 smuel
Am Sonntag, 22. September 2013, 16:38:53 schrieb Theodore Ts'o:
Hi Theodore,
Allow architectures which have a disabled get_cycles() function to
provide a random_get_entropy() function which provides a fine-grained,
rapidly changing counter that can be used by the /dev/random driver.
Are there
Am Freitag, 6. Juni 2014, 13:59:00 schrieb Pavel Machek:
Hi Pavel,
On Mon 2014-05-12 00:36:01, Stephan Mueller wrote:
Hi,
as discussed in thread [1], an in-kernel equivalent to the blocking
/dev/random device behavior is suggested. This in-kernel blocking
access to the RNG can be used
that is invoked once the
request is completed.
A third API call, get_blocking_random_bytes_cancel, is provided to
cancel the random number gathering operation.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
drivers/char/random.c | 113
fully equally to the blocking and
nonblocking pool with respect to the initialization and update. As now
there are three output pools, the patch adds a round-robin logic for
processing additional entropy when the input_pool is nearly full.
Signed-off-by: Stephan Mueller smuel...@chronox.de
the
collection process is ongoing.
[1] https://lkml.org/lkml/2014/4/27/174
Stephan Mueller (2):
Addition of kernel_pool
Asynchronous and syncronous API for accessing kernel_pool
drivers/char/random.c | 163
+
include/linux/random.h | 16 +
2
Hi Peter,
some time back when the RDRAND instruction was debated, a patch was offered
for driver/char/random.c that in essence turned /dev/random into a frontend
for RDRAND in case that instruction was available. The patch kind of
monopolized the noise sources such that if a user space random
not covered with specific test cases.
All currently implemented DRBG types and backend ciphers are defined
in SP800-90A. Therefore, the fips_allowed flag is set for all.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/testmgr.c | 248
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/Makefile b/crypto/Makefile
index 38e64231..bfa94fa 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj
of SHA-512.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/testmgr.h | 843 +++
1 file changed, 843 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 3db83db..0030ff5 100644
--- a/crypto/testmgr.h
+++ b/crypto
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled
at compile time. At least one DRBG type shall be selected.
The default is the HMAC DRBG as its code base is smallest.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/Kconfig | 36
1 - 100 of 1820 matches
Mail list logo
