[PATCH v3 1/5] crypto: DRBG - externalize DRBG functions for LRNG

>From 443dd61dcf2cf5a7a516c552da463ee2d8aea949 Mon Sep 17 00:00:00 2001 From: Stephan Mueller <smuel...@chronox.de> Date: Mon, 18 Apr 2016 10:04:33 +0200 Subject: This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by

[PATCH v3 5/5] random: add interrupt callback to VMBus IRQ handler

the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by: Stephan Mueller <stephan.muel...@atsec.com> Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- drivers/char/random.c | 1 + drivers/hv/vmbus_drv.c | 3 +++ 2 files changed,

[PATCH v3 3/5] crypto: Linux Random Number Generator

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/lrng.c | 1914 + 1 file changed, 1914 insertions(+) create mode 100644 crypto/lrng.c diff --git a/

Re: random(4) changes

Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin: Hi George, > (Note that we have two chains of e-mails crossing mid-stream. I'm in > the middle of working on a much longer reply to your previous e-mail.) > > >> They're not independent, nor are they identically distributed. > > > >

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: Hi Richard, > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > Signed-off-by: Richard W.M. Jones > --- >

Re: random(4) changes

Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin: Hi George, > > I think there is a slight mixup: IID is not related to an attacker > > predicting things. IID is simply a statistical measure, it is either there > > or not. It does not depend on an attacker (assuming that the attacker

Re: random(4) changes

Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen: Hi Andi, > > > > If it is the latter, can you explain where the scalability issue comes > > > > in? > > > > > > A single pool which is locked/written to does not scale. Larger systems > > > need multiple pools > > > > That would imply

Re: random(4) changes

Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen: Hi Andi, > > > > If it is the latter, can you explain where the scalability issue comes > > > > in? > > > > > > A single pool which is locked/written to does not scale. Larger systems > > > need multiple pools > > > > That would imply

Re: random(4) changes

Am Dienstag, 26. April 2016, 16:43:30 schrieb George Spelvin: Hi George, (I am not covering the initial part as I leave you time to read through the paper which should cover those aspects) > > That's what I don't like about Intel's RDRAND and similar hardware RNGs: > they are whitening too

Re: random(4) changes

Am Freitag, 22. April 2016, 18:27:48 schrieb Sandy Harris: Hi Sandy, > Stephan has recently proposed some extensive changes to this driver, > and I proposed a quite different set earlier. My set can be found at: > https://github.com/sandy-harris > > This post tries to find the bits of both

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Sonntag, 24. April 2016, 23:25:00 schrieb Pavel Machek: Hi Pavel, > > /* This RNG does not work if no high-resolution timer is available */ > > BUG_ON(!random_get_entropy() && !random_get_entropy()); > > Heh, does this cause BUG() with 2^-64 probability? :-). No, but for the listed arches,

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Montag, 25. April 2016, 09:55:14 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller <smuel...@chronox.de> wrote: > >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > >> > This is commonly achieved ev

Re: random(4) changes

Am Samstag, 23. April 2016, 22:03:23 schrieb Theodore Ts'o: Hi Theodore, > On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote: > > I really like Stephan's idea of simplifying the interrupt handling, > > replacing the multiple entropy-gathering calls in the current driver > > with one

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

Re: random(4) changes

Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin: Hi George, > > And considering that I only want to have 0.9 bits of entropy, why > > should I not collapse it? The XOR operation does not destroy the existing > > entropy, it only caps it to at most one bit of information theoretical

Re: random(4) changes

Am Montag, 25. April 2016, 23:07:35 schrieb Theodore Ts'o: Hi Theodore, > > > When dropping the add_disk_randomness function in the legacy /dev/random, > > I > > would assume that without changes to add_input_randomness and > > add_interrupt_randomness, we become even more entropy-starved. > >

Re: random(4) changes

Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin: Hi George, > > > not the rest of Stephan's input handling code: the parity > > calculation and XORing the resulting single bit into the entropy pool. > > Indeed, this is an incredibly popular novice mistake and I don't > understand why

Re: random(4) changes

Am Dienstag, 26. April 2016, 20:44:39 schrieb Pavel Machek: Hi Pavel, > Hi1 > > > > When dropping the add_disk_randomness function in the legacy > > > /dev/random, I > > > would assume that without changes to add_input_randomness and > > > add_interrupt_randomness, we become even more

Re: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm

Am Donnerstag, 19. Mai 2016, 15:15:15 schrieb Tudor Ambarus: Hi Tudor, as I am looking into the RSA countermeasures, I am wondering how much of countermeasures are actually applied inside hardware implementations. Can you please point me to or illustrate any countermeasures your implementation

key retention service: DH support

Hi David, With the new DH support for the key retention service, support for DH derived keys pops up. The implementation in security/keys/dh.c returns the DH shared secret straight to the user space caller. I implemented a KDF with that exact scenario already in mind: [1]. I am wondering

Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API

Am Mittwoch, 11. Mai 2016, 08:26:00 schrieb Salvatore Benedetto: Hi Salvatore, > Hi Herb, > > the following patchset introduces a new API for abstracting key-agreement > protocols such as DH and ECDH. It provides the primitives required for > implementing the protocol, thus the name KPP

Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API

Am Montag, 23. Mai 2016, 20:26:15 schrieb Benedetto, Salvatore: Hi Salvatore, > > http://permalink.gmane.org/gmane.linux.kernel.lsm/27456 > > As mentioned in the cover letter of that patch, KEYCTL_DH_COMPUTE will be > converted to kpp once accepted. Ok, I have overlooked that one :-)

ATH9K RNG

Hi Miaoqing, Kalle, considering the patch ed14dc0af7ccea867b479feb88efdfe43ca2a0f9 which adds the invocation of add_hwgenerator_randomness to the ATH9K driver, may I ask about more details about how you concluded that the data from the ATH chip is entropic? In addition, can you please

Re: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm

Am Montag, 23. Mai 2016, 12:56:18 schrieb Tudor-Dan Ambarus: Hi Tudor, > Hi Stephan, > > > as I am looking into the RSA countermeasures, I am wondering how much of > > countermeasures are actually applied inside hardware implementations. > > Please point me to the reference RSA countermeasures

Re: key retention service: DH support

Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells: Hi David, > Stephan Mueller <smuel...@chronox.de> wrote: > > The KDF patches are fully tested. All that would be needed on the key > > retention side after the shared secret generation are the followin

Re: key retention service: DH support

Am Dienstag, 24. Mai 2016, 09:22:22 schrieb Mat Martineau: Hi Mat, Herbert > > KDF transformations would be extremely useful, but transforming the DH > output using a KDF needs to be configurable. There are enough different > uses for DH that it's important to have access to the raw values. > >

Re: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm

Am Dienstag, 24. Mai 2016, 16:13:48 schrieb Tudor-Dan Ambarus: Hi Tudor, > Hi Stephan, > > > > > as I am looking into the RSA countermeasures, I am wondering how much > > > > of > > > > > > countermeasures are actually applied inside hardware implementations. > > > > > > Please point me to

pkcs1pad_verify_complete: decoding missing?

Hi, I am experimenting with pkcs1pad(rsa-generic) signature verify. The following numbers shall serve as examples -- using other valid signatures, similar results are visible. All signatures are correct. The result of the signature verify operation is the following byte stream:

Re: pkcs1pad_verify_complete: decoding missing?

Am Montag, 9. Mai 2016, 11:15:04 schrieb Tadeusz Struk: Hi Tadeusz, > Hi Strphan, > > On 05/09/2016 03:24 AM, Stephan Mueller wrote: > > Hi, > > > > I am experimenting with pkcs1pad(rsa-generic) signature verify. The > > following numbers shall serve

Re: pkcs1pad_verify_complete: decoding missing?

Am Montag, 9. Mai 2016, 11:55:58 schrieb Tadeusz Struk: Hi Tadeusz, > On 05/09/2016 11:50 AM, Stephan Mueller wrote: > > I think I see my error: pkcs1pad(rsa,HASH) -- I missed the hash part that > > activates the decoding. Thank you for the pointer. > > > > Once I co

Re: pkcs1pad_verify_complete: decoding missing?

Am Montag, 9. Mai 2016, 12:17:21 schrieb Tadeusz Struk: Hi Tadeusz, > On 05/09/2016 12:02 PM, Stephan Mueller wrote: > > One followup: is the final memcmp() between the decrypted hash and the > > hash of the message implemented in the RSA verify code path? At least I > > do

Re: Typos and RSA

Am Dienstag, 17. Mai 2016, 16:22:43 schrieb Gary R Hook: Hi Gary, > I am working on hooking up RSA functionality to the akcipher API. It appears > that no other code, to date, uses this API. Can anyone confirm or deny that > conclusion? This is not correct. The asymmetric key API uses that

Re: Typos and RSA

ecompose the two parts > of src and get their lengths? What can we expect on the receiving end of > the encrypt > function with respect to the source data structure? A two-element > scatterlist? Or...? > What can we conclude from the calls made in do_test_rsa() in testmgr.c, > vs the call in >

Costs of asym self tests

Hi, albeit it makes most sense to have asym self tests in the test manager as we do right now, may I suggest some changes to it as follows. The issue I see is that asym operations are very expensive. As we currently have RSA only, I can only refer to its implementation. But in general, all

[PATCH] crypto: user - no parsing of CRYPTO_MSG_GETALG

-by: Stephan Mueller <smuel...@chronox.de> --- crypto/crypto_user.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c index 43fe85f..f71960d 100644 --- a/crypto/crypto_user.c +++ b/crypto/crypto_user.c @@ -516,10 +

Re: Decrypting data in RX path

Am Montag, 16. Mai 2016, 17:24:12 schrieb Gadre Nayan: Hi Gadre, > Hi, > > I am able to encrypt data using the asynchronous kernel crypto API's. > I can observe the encrypted data on the protocol analyzer. > > I wanted to decry-pt the data now on the receiver side, So I have > following

[PATCH] crypto: Intel SHA - add MODULE_ALIAS

Add the MODULE_ALIAS for the cra_driver_name of the different ciphers to allow an automated loading if a driver name is used. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- arch/x86/crypto/sha1_ssse3_glue.c | 6 ++ arch/x86/crypto/sha256_ssse3_glue.c | 10 ++ ar

Re: Decrypting data in RX path

: Monday, May 16, 2016 5:40 PM > To: Stephan Mueller; linux-crypto@vger.kernel.org > Subject: Re: Decrypting data in RX path > > Hi, > > 1. The context of the question "best place to decrypt in > kernel(module/driver)" is I want to encrypt network packets sent from

Re: IV generation in cryptographic driver in AEAD

Am Mittwoch, 18. Mai 2016, 15:06:19 schrieb Denis B: Hi Denis, > Hello, > > In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel > versions prior to 4.2 the cryptographic driver is expected to generate > an IV. The driver is not expected to generate the IV. Please see the ASCII

Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API

Am Mittwoch, 11. Mai 2016, 08:26:00 schrieb Salvatore Benedetto: Hi Salvatore, > Changes from v5: > * Fix ecdh loading in fips mode. Thanks. As I do not readily see how you solved the issue, may I ask for a pointer to the code that handles that? Ciao Stephan -- To unsubscribe from this list:

Re: [PATCH v6 0/6] crypto: algif - add akcipher

Am Samstag, 14. Mai 2016, 21:16:45 schrieb Tadeusz Struk: Hi Tadeusz, > First four patches are a resend of the v3 algif_akcipher from > Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. All four patches from me: Acked-by: Stephan Mueller <smuel...@chronox.de>

Re: random(4) changes

Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin: Hi George, > > What I am saying that the bits in one given time stamp are mutually > > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > > very same time stamp. > > And I'm saying that's wrong. I think we

Re: skcipher

ng\n"); > crypto_free_skcipher(skcipher); > } > if(!IS_ERR(req)){ > pr_err("NO_ERR: REQ: Reached here because something > else failed\n"); > skcipher_request_free(req); > } > if(!IS_E

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. In general, I have no concerns with this approach either. And thank you that some of my concerns are addressed. There are few more

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, One more item. > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- >

Re: [PATCH 3/3 v4] crypto: kpp - Add ECDH software support

Am Donnerstag, 5. Mai 2016, 10:17:37 schrieb Salvatore Benedetto: Hi Salvatore, > * Implement ECDH under kpp API > * Provide ECC software support for curve P-192 and >P-256. > * Add kpp test for ECDH with data generated by OpenSSL > > Signed-off-by: Salvatore Benedetto

Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

Am Donnerstag, 5. Mai 2016, 12:51:20 schrieb Tadeusz Struk: Hi Tadeusz, > This patch adds support for asymmetric key type to AF_ALG. > It will work as follows: A new PF_ALG socket options are > added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely > ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 09:48:57 schrieb Theodore Ts'o: Hi Theodore, > On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > > - entropy pool draining: when having a timer-based reseeding on a quiet > > > system, the entropy pool can be drained during the expiry of the timer. > > >

Re: skcipher

ependencies). Well, a 32 bit system does not have AES-NI support. > > I think I am still missing something. Any hardware feature. Or some > other module is using some IRQ or region which is not shared. > > Thanks. > Nayan Gadre. > > On Mon, May 2, 2016 at 11:21 AM,

Re: Crypto hash function decryption

gt; kernel version. > > The latest kernel 4.5 has skcipher fully implemented but I need to work > with 3.19. Please read the kernel crypto API documentation: http://www.chronox.de/crypto-API/index.html > > Thanks > > On 1 May 2016 6:54 p.m., "Stephan Mueller" &l

Re: Crypto hash function decryption

Am Sonntag, 1. Mai 2016, 18:35:51 schrieb Gadre Nayan: Hi Gadre, > Hi, > > I wanted to implement a simple encryption decryption of data in kernel > space to start with the kernel crypto library. > > I have the following: > > int myFunction() { > > struct scatterlist sg; >

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o: Hi Theodore, I have not digested the patch set yet, but I have the following questions to your patch set. > On a system with a 4 socket (NUMA) system where a large number of > application processes were all trying to read from

Re: [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API

Am Donnerstag, 5. Mai 2016, 12:50:54 schrieb Tadeusz Struk: Hi Tadeusz, David, > From: Stephan Mueller <smuel...@chronox.de> > > Add the flags for handling signature generation and signature > verification. > > Also, the patch adds the interface for setting a pub

Re: [PATCH v5 0/3] Key-agreement Protocol Primitives (KPP) API

Am Montag, 9. Mai 2016, 22:40:38 schrieb Salvatore Benedetto: Hi Salvatore, > Hi Herb, > > the following patchset introduces a new API for abstracting key-agreement > protocols such as DH and ECDH. It provides the primitives required for > implementing the protocol, thus the name KPP

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c |

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Dienstag, 3. Mai 2016, 11:36:12 schrieb Stephan Mueller: Hi Ted, > > + > > +static ssize_t extract_crng_user(void __user *buf, size_t nbytes) > > +{ > > + ssize_t ret = 0, i; > > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > > + int large_request = (nbytes

Re: [PATCH v3 2/3] crypto: rsa_helper - add raw integer parser actions

Am Donnerstag, 14. April 2016, 15:25:17 schrieb Tudor-Dan Ambarus: Hi Tudor, > > > > > +{ > > > + if (key->d) { > > > + memset(key->d, '\0', key->n_sz); > > > > memzero_explicit, please > > I don't think this is really needed. memzero_explicit is used only on stack > variables that

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller <smuel...@chronox.de> wrote: > > Hi Herbert, Ted, > > > > The venerable Linux /dev/random served users of cryptographic mechanis

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > > [quote from pdf] > > > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > > This is commonly achieved even before user space is initiated. > > Unfortunately one of the issues of the /dev/urandom

[PATCH 5/6] crypto: LRNG - hook LRNG into interrupt handler

The LRNG places a callback into the interrupt handler to be triggered for each interrupt. With this callback, entropy is collected. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- kernel/irq/handle.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/irq/handle.c b/kern

[PATCH 2/6] random: conditionally compile code depending on LRNG

-off-by: Stephan Mueller <smuel...@chronox.de> --- drivers/char/random.c | 8 include/linux/genhd.h | 5 + include/linux/random.h | 8 3 files changed, 21 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index b583e53..92c2174 100644 --- a/driver

[PATCH 6/6] hyperv IRQ handler: trigger LRNG

-by: Stephan Mueller <smuel...@chronox.de> --- drivers/hv/vmbus_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 64713ff..afa2de0 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -41,6 +41,7 @@ #include #i

[PATCH 4/6] crypto: LRNG - enable compile

Add LRNG compilation support. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 93a1fdc..938f2dc 100644 --- a/crypto/Kconfig +++ b/crypto/K

[PATCH 3/6] crypto: Linux Random Number Generator

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/lrng.c | 1803 + 1 file changed, 1803 insertions(+) create mode 100644 crypto/lrng.c diff --git a/

[RFC][PATCH 0/6] /dev/random - a new approach

doc/lrng.pdf [2] http://www.chronox.de/lrng.html Stephan Mueller (6): crypto: DRBG - externalize DRBG functions for LRNG random: conditionally compile code depending on LRNG crypto: Linux Random Number Generator crypto: LRNG - enable compile crypto: LRNG - hook LRNG into interrupt hand

[PATCH 1/6] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 del

Re: tcrypt failing on hmac(crc32)

Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner: Hi Marcus, > Hi, > > when enabling the testmgr framework and FIPS in 4.6 and 4.4 and running > "modprobe tcrypt" }, { .alg = "hmac(crc32)", .test = alg_test_hash, ... fips_allowed = 1 missing?

Re: tcrypt failing on hmac(crc32)

Am Mittwoch, 25. Mai 2016, 13:36:10 schrieb Marcus Meissner: Hi Marcus, > Hi, > > On Wed, May 25, 2016 at 09:10:31AM +0200, Stephan Mueller wrote: > > Am Mittwoch, 25. Mai 2016, 09:07:52 schrieb Marcus Meissner: > > > > Hi Marcus, > > > > > Hi, > &

Re: [PATCH] DH support: add KDF handling support

Am Mittwoch, 27. Juli 2016, 08:55:31 CEST schrieb David Howells: Hi David, > Mat Martineau wrote: > > > Though, shall I stuff the wrapper code back into the existing dh_compute > > > functions or can I leave them as separate functions? > > > > I'm not sure.

[PATCH] DH support: add KDF handling support

information string: dh_compute The test to verify the code is based on a test vector used for the CAVS testing of SP800-56A. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- keyctl.c | 14 +- keyutils.c | 48 ++

[PATCH v3 4/4] crypto: kdf - enable compilation

Include KDF into Kconfig and Makefile for compilation. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 7 +++ crypto/Makefile | 1 + 2 files changed, 8 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 62fcbb9..7779af8 100644 --- a/crypto/K

[PATCH v3 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/testmgr.c | 226 +++ crypto/testmgr.h | 110 +++ 2 files changed, 336 inse

[PATCH v3 3/4] crypto: kdf - SP800-108 Key Derivation Function

-by: Stephan Mueller <smuel...@chronox.de> --- crypto/kdf.c | 514 +++ 1 file changed, 514 insertions(+) create mode 100644 crypto/kdf.c diff --git a/crypto/kdf.c b/crypto/kdf.c new file mode 100644 index 000..b39bddf --- /dev/null

[PATCH v3 0/4] crypto: Key Derivation Function (SP800-108)

in the first patch by adding a template handling for random number generators based on the same logic as for keyed hashes. Changes v3: * port testmgr patch to current cryptodev-2.6 tree * add non-keyed KDF references to testmgr.c Changes v2: * port to 4.7-rc1 Stephan Mueller (4): crypto: add

[PATCH v3 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller <smuel...@chronox.de

Re: [PATCH] DH support: add KDF handling support

Am Donnerstag, 14. Juli 2016, 04:00:57 schrieb Jeffrey Walton: Hi Jeffrey, > > Note, as shared secrets potentially post-processed by a KDF usually are > > again used as key or data encryption keys, they need to be > > truncated/expanded to a specific length anyway. A KDF inherently provides > >

Re: getrandom waits for a long time when /dev/random is insufficiently read from

Am Donnerstag, 28. Juli 2016, 18:07:32 CEST schrieb Alex Xu: Hi Alex, > Linux 4.6, also tried 4.7, qemu 2.6, using this C program: I am not sure what problem you are referring to, but that is an expected behavior. You get partial reads when reading from /dev/random with a minimum of 64 bits.

Re: getrandom waits for a long time when /dev/random is insufficiently read from

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <n...@gnutls.org> wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > <smuel...@chronox.de> wrote: >

Re: a few questions on AF_ALG specification (AEAD, socket/connection, ...)

ng: The key is set on a socket. The IV is given with the connection. > > NB > > > > - Mail original - > De: "Tadeusz Struk" <tadeusz.st...@intel.com> > À: "Stephan Mueller" <smuel...@chronox.de>, "Nicolas Brunie"

Re: a few questions on AF_ALG specification (AEAD, socket/connection, ...)

Am Dienstag, 26. Juli 2016, 13:48:21 CEST schrieb Nicolas Brunie: Hi Nicolas, > Hi All, > I am developping a driver for a crypto offloading solution which > uses the AF_ALG interface. I am trying to stay as close as possible to > the specification but apart from the kernel crypto source code

[PATCH v6 2/5] random: conditionally compile code depending on LRNG

-off-by: Stephan Mueller <smuel...@chronox.de> --- drivers/char/random.c | 8 include/linux/genhd.h | 5 + include/linux/random.h | 7 ++- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 3efb3bf..730a12e

[PATCH v6 1/5] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 del

[PATCH v6 3/5] crypto: Linux Random Number Generator

n addition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the legacy /dev/random implementation. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/lrng_base.c | 1960 +++ cry

[PATCH v6 4/5] crypto: LRNG - enable compile

Add LRNG compilation support. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 11 +++ crypto/Makefile | 2 ++ 2 files changed, 13 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 84d7148..71df7fc 100644 --- a/crypto/Kconfig +++ b/

[PATCH v6 0/5] /dev/random - a new approach

it for seeding cryptographic daemons. Note, this test result was obtained for different architectures, such as x86 64 bit, x86 32 bit, ARM 32 bit and MIPS 32 bit. [1] http://www.chronox.de/lrng/doc/lrng.pdf [2] http://www.chronox.de/lrng.html Stephan Mueller (5): crypto: DRBG - externalize DRBG

[PATCH v6 5/5] crypto: LRNG - add ChaCha20 support

numbers. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 1 - crypto/Makefile | 7 +- crypto/lrng_standalone.c | 220 +++ 3 files changed, 226 insertions(+), 2 deletions(-) create mode 100644

Re: [PATCH v6 4/5] crypto: LRNG - enable compile

Am Donnerstag, 11. August 2016, 21:50:15 CEST schrieb kbuild test robot: Hi, > Hi Stephan, > > [auto build test ERROR on cryptodev/master] > [also build test ERROR on v4.8-rc1] > [cannot apply to next-20160811] > [if your patch is applied to the wrong git tree, please drop us a note to > help

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi: Hi Tapas, Herbert, > Hi Stephan, > > Thanks. I have already tried that. ‘drbg’ module is loaded fine in a > non-fips mode. Here are output from some commands. There is something strange going on. I have to compile the DRBG

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > Following up from the other thread: > > While trying to boot in FIPS mode, kernel panics with the following > message. So far, I don¹t have success to get more information about which > module or

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > Would you please provide a recent NIST document which asks the entropy > source to pass the NIST randomness tests ? See FIPS 140-2 IG 7.15 which explicitly references SP800-22. Ciao Stephan -- To

[PATCH] crypto: XTS - remove test that will fail in FIPS mode

sts available for XTS, this patch simply removes the offending test vectors. Reported-by: Tapas Sarangi <tsara...@trustwave.com> Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/testmgr.h | 36 1 file changed, 36 deletions(-) diff

[PATCH v4] KEYS: add SP800-56A KDF support for DH

ested size, this patch fills the caller buffer up to its size. The patch is tested with a new test added to the keyutils user space code which uses a CAVS test vector testing the compliance with SP800-56A. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- Documentation/securit

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > FIPS RNG test is supposed to be run on the output of an RNG, and not on the > RNG entropy source. It is not surprising that the RNG input fails the > entropy tests from NIST. Check the following

[PATCH v4] DH support: add KDF handling support

ith "other information string: dh_compute_kdf_oi where the OI string is provided on STDIN. The test to verify the code is based on a test vector used for the CAVS testing of SP800-56A. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- Makefile

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > For those less perfect noise source, can't pass the FIPS test. > > static int update_kernel_random(int random_step, > unsigned char *buf, fips_ctx_t *fipsctx_in) > { > unsigned

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the > amount of min entropy the source provides, and not to decide if the source > has passed the tests or failed. See > >

Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH

Am Dienstag, 9. August 2016, 15:48:00 CEST schrieb Mat Martineau: Hi Mat, > On Sat, 6 Aug 2016, Stephan Mueller wrote: > > diff --git a/security/keys/internal.h b/security/keys/internal.h > > index a705a7d..7659b52 100644 > > --- a/security/keys/internal.h > > +++

Re: [PATCH] crypto: XTS - remove test that will fail in FIPS mode

Am Donnerstag, 11. August 2016, 19:42:54 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > Any other ideas about this problem ? Since XTS is not amongst the > self-tests as you observed, is it safe to disable .fips_allowed for > xts(aes) in testmgr.c ? If you do that, none of your XTS

Re: JZ4780 RNG and entropy depletion

Am Sonntag, 14. August 2016, 01:33:32 CEST schrieb Jeffrey Walton: Hi Jeffrey, > Hi Everyone, > > I have a MIPSEL ci20 dev board for testing. The board has a hardware > based rng, but its suffering entropy depletion. I have Debian's > rng-tools package installed. > > The board lacks

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Freitag, 12. August 2016, 15:22:08 CEST schrieb Theodore Ts'o: Hi Theodore, > On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote: > > - correlation: the interrupt noise source is closely correlated to the > > HID/ > > block noise sources. I see that the fast

<    5   6   7   8   9   10   11   12   13   >