Re: DRBG parallel requests

Am Donnerstag, 16. April 2015, 23:30:38 schrieb Herbert Xu: Hi Herbert, >On Thu, Apr 16, 2015 at 05:13:50PM +0200, Stephan Mueller wrote: >> Surely, the shadow approach scales better than a global lock. But its >> drawback is the (almost) identical state. > >The drawback is

Re: DRBG seeding

in-kernel /dev/random -- this again should seed the DRBG with entropy as it becomes available. But thank you for your support. It is surely helpful to show also to Ted Tso that an update to /dev/random is of interest to various users. Ciao Stephan > > Best regards > > Andreas

Re: DRBG seeding

Am Freitag, 17. April 2015, 10:14:30 schrieb Herbert Xu: Hi Herbert, > On Fri, Apr 17, 2015 at 03:19:17AM +0200, Stephan Mueller wrote: > > 1. during initialization of a DRBG instance, seed from get_random_bytes to > > have a DRBG state that is seeded and usable. > > I th

[PATCH 3/4] crypto: drbg - replace spinlock with mutex

a random number. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 22 ++ include/crypto/drbg.h | 4 ++-- 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index c8a083c..19916ea 100644 --- a/crypto/drbg.c +++ b/crypto

[PATCH 4/4] crypto: drbg - leave cipher handles operational

As the DRBG does not operate on shadow copies of the DRBG instance any more, the cipher handles only need to be allocated once during initalization time and deallocated during uninstantiate time. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 12 1 file changed, 4 insertions

[PATCH 1/4] cryoto: drbg - clear all temporary memory

The buffer uses for temporary data must be cleared entirely. In AES192 the used buffer is drbg_statelen(drbg) + drbg_blocklen(drbg) as documented in the comment above drbg_ctr_df. This patch ensures that the temp buffer is completely wiped. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 2

[PATCH 2/4] crypto: drbg - do not create shadow copy

creation and maintenance of a shadow copy can be removed. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 122 ++ 1 file changed, 11 insertions(+), 111 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 8d2944f..c8a083c 100644

[PATCH 0/4] crypto: drbg - revamp locking

high-resolution timer that was mixed in during the shadow state generation. This patch now removes this shadow state and introduces a mutex to serialize all requests to one DRBG instance. The patch was fully CAVS tested and demonstrates that the DRBG still complies with the standard. Stephan

Re: DRBG seeding

Am Freitag, 17. April 2015, 21:11:37 schrieb Herbert Xu: Hi Herbert, > On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote: > > Do you really think that this is possible? If the DRBG becomes the stdrng, > > you would imply that those callers (e.g. IPSEC) may suf

Re: DRBG seeding

Am Samstag, 18. April 2015, 09:27:44 schrieb Herbert Xu: Hi Herbert, > On Fri, Apr 17, 2015 at 03:22:56PM +0200, Stephan Mueller wrote: > > > The only reason someone would use this is to comply with the > > > standard and this is what the standard requires so I don'

Re: DRBG seeding

Am Samstag, 18. April 2015, 09:36:18 schrieb Herbert Xu: Hi Herbert, > On Sat, Apr 18, 2015 at 03:32:03AM +0200, Stephan Mueller wrote: > > In any case, I am almost ready with the patch for an async seeding. > > Though, I want to give it a thorough testing. > > I don

Re: [PATCH 3/4] crypto: drbg - replace spinlock with mutex

Am Samstag, 18. April 2015, 18:55:23 schrieb Herbert Xu: Hi Herbert, > > Incidentally the whole reset concept seems redundant as you could > always free and allocate a new RNG instead. So I'm planning on > replacing it with a seed/reseed function instead. IOW it will > keep the existing state

Re: [PATCH 2/4] crypto: drbg - do not create shadow copy

Am Samstag, 18. April 2015, 18:49:43 schrieb Herbert Xu: Hi Herbert, > On Fri, Apr 17, 2015 at 02:54:58PM +0200, Stephan Mueller wrote: > > The creation of a shadow copy is intended to only hold a short term > > lock. But the drawback is that parallel users have a very similar

[PATCH v2 3/3] crypto: drbg - leave cipher handles operational

As the DRBG does not operate on shadow copies of the DRBG instance any more, the cipher handles only need to be allocated once during initalization time and deallocated during uninstantiate time. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 12 1 file changed, 4 insertions

[PATCH v2 1/3] crypto: drbg - fix drbg_generate return val check

The drbg_generate returns 0 in success case. That means that drbg_generate_long will always only generate drbg_max_request_bytes at most. Longer requests will be truncated to drbg_max_request_bytes. Reported-by: Herbert Xu Signed-off-by: Stephan Mueller --- crypto/drbg.c | 2 +- 1 file changed

[PATCH v2 0/3] crypto: drbg - revamp locking

generation as both patches cannot stand alone and would therefore break bisection * drop patch that fixes the memory release (Herbert: you mentioned the patch is applied but it is not yet in the repo -- this patch is vital as otherwise AES192 now breaks without the shadow copy operation) Stephan

[PATCH v2 2/3] crypto: drbg - replace spinlock with mutex

states, the entire creation and maintenance of a shadow copy can be removed. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 144 +- include/crypto/drbg.h | 4 +- 2 files changed, 27 insertions(+), 121 deletions(-) diff --git a/crypto

Re: [PATCH v2 1/3] crypto: drbg - fix drbg_generate return val check

Am Samstag, 18. April 2015, 16:42:20 schrieb Stephan Mueller: Hi Stephan, > The drbg_generate returns 0 in success case. That means that > drbg_generate_long will always only generate drbg_max_request_bytes at > most. Longer requests will be truncated to drbg_max_request_bytes. > &

[PATCH v3 1/3] crypto: drbg - fix drbg_generate return val check

The drbg_generate returns 0 in success case. That means that drbg_generate_long will always only generate drbg_max_request_bytes at most. Longer requests will be truncated to drbg_max_request_bytes. Reported-by: Herbert Xu Signed-off-by: Stephan Mueller --- crypto/drbg.c | 14 +++--- 1

[PATCH v3 3/3] crypto: drbg - leave cipher handles operational

As the DRBG does not operate on shadow copies of the DRBG instance any more, the cipher handles only need to be allocated once during initalization time and deallocated during uninstantiate time. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 12 1 file changed, 4 insertions

[PATCH v3 2/3] crypto: drbg - replace spinlock with mutex

states, the entire creation and maintenance of a shadow copy can be removed. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 144 +- include/crypto/drbg.h | 4 +- 2 files changed, 27 insertions(+), 121 deletions(-) diff --git a/crypto

[PATCH v3 0/3] crypto: drbg - revamp locking

: * patch for fixing the return code handling in drbg_generate_long did not cover all code paths -- now the issue should be truly fixed Stephan Mueller (3): crypto: drbg - fix drbg_generate return val check crypto: drbg - replace spinlock with mutex crypto: drbg - leave cipher handles

Re: [PATCH v3 0/3] crypto: drbg - revamp locking

Am Sonntag, 19. April 2015, 13:49:31 schrieb Herbert Xu: Hi Herbert, > On Sat, Apr 18, 2015 at 07:35:11PM +0200, Stephan Mueller wrote: > > Hi, > > > > the current implementation of the DRBG generates a shadow copy of its > > DRBG state for each incoming request. Th

Re: [PATCH 3/4] crypto: drbg - replace spinlock with mutex

Am Sonntag, 19. April 2015, 13:48:03 schrieb Herbert Xu: Hi Herbert, > On Sat, Apr 18, 2015 at 01:35:40PM +0200, Stephan Mueller wrote: > > When you do that, may I ask you to also update the crypto_alloc_rng. This > > function has one major drawback at the moment: we are w

Re: [PATCH 3/4] crypto: drbg - replace spinlock with mutex

Am Montag, 20. April 2015, 08:27:09 schrieb Herbert Xu: Hi Herbert, >On Sun, Apr 19, 2015 at 05:37:21PM +0200, Stephan Mueller wrote: >> I am not sure I understand you correctly: shall the DRBG have these >> precautions? If so, wouldn't we break the requirements in SP800-90A

Re: [PATCH 3/4] crypto: drbg - replace spinlock with mutex

Am Montag, 20. April 2015, 08:48:55 schrieb Herbert Xu: Hi Herbert, >On Mon, Apr 20, 2015 at 02:45:02AM +0200, Stephan Mueller wrote: >> I do not want to deviate from the kernel crypto API by adding some >> additional wrapper. But what we can do is to leave the DRBG unseeded >&

Re: crypto: drbg - Initialise mutex in drbg_healthcheck_sanity

Am Montag, 20. April 2015, 11:26:48 schrieb Herbert Xu: Hi Herbert, > As we moved the mutex init out of drbg_instantiate and into cra_init > we need to explicitly initialise the mutex in drbg_healthcheck_sanity. > > Signed-off-by: Herbert Xu Acked-by: Stephan Mueller > > d

Re: [PATCH 6/15] crypto: rng - Mark crypto_rng_reset seed as const

Am Montag, 20. April 2015, 13:39:05 schrieb Herbert Xu: Hi Herbert, > There is no reason why crypto_rng_reset should modify the seed > so this patch marks it as const. Since our algorithms don't > export a const seed function yet we have to go through some > contortions for now. > > Signed-off-

Re: crypto: drbg - Do not seed RNG in drbg_kcapi_init

rbg_uninstantiate because > it's now only called from the destruction path which must not be > executed in parallel with normal operations. > > Signed-off-by: Herbert Xu Acked-by: Stephan Mueller > > diff --git a/crypto/drbg.c b/crypto/drbg.c > index 57fd479..5bce15

Re: [v2 PATCH 0/11] rng: New style interface

> type added before the introduction of the new style. > > Eventually all existing interfaces should be converted over but > obviously it's taking some time to get there :) > > v2 uses kzfree instead of free for the temporary seed. > > Cheers, For the DRBG changes: Acked-by:

module ref count

Hi Herbert, I am currently working on the template for SP800-38F key wrapping. The module is operational and calculates what I want. However, I have one problem I am having difficulties to track down and I am wondering whether you could point me to the right direction. When a caller calls

Re: module ref count

Am Dienstag, 21. April 2015, 14:35:47 schrieb Stephan Mueller: Hi Stephan, > Hi Herbert, > > I am currently working on the template for SP800-38F key wrapping. The > module is operational and calculates what I want. > > However, I have one problem I am having difficulties t

Re: module ref count

Am Dienstag, 21. April 2015, 14:56:31 schrieb Stephan Mueller: Hi Stephan, > Am Dienstag, 21. April 2015, 14:35:47 schrieb Stephan Mueller: > > Hi Stephan, > > > Hi Herbert, > > > > I am currently working on the template for SP800-38F key wrapping. The > >

Re: crypto: drbg - Remove FIPS ifdef from drbg_healthcheck_sanity

Am Mittwoch, 22. April 2015, 11:42:35 schrieb Herbert Xu: Hi Herbert, > This patch removes the unnecessary CRYPTO_FIPS ifdef from > drbg_healthcheck_sanity so that the code always gets checked > by the compiler. > > Signed-off-by: Herbert Xu Acked-by: Stephan Mueller -- Cia

[PATCH] crypto: add key wrapping block chaining mode

bytes. Testing with CAVS test vectors for AES 128, 192, 256 in encryption and decryption up to 4096 bytes plaintext has been conducted successfully. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 6 + crypto/Makefile | 1 + crypto/keywrap.c | 518

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu: Hi Herbert, > On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote: > > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote: > > > The key wrapping is an authenticated encryption operation without >

Re: crypto: fips - Move fips_enabled sysctl into fips.c

Am Mittwoch, 22. April 2015, 13:02:22 schrieb Herbert Xu: Hi Herbert, > There is currently a large ifdef FIPS code section in proc.c. > Ostensibly it's there because the fips_enabled sysctl sits under > /proc/sys/crypto. However, no other crypto sysctls exist. > > In fact, the whole ethos of th

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Mittwoch, 22. April 2015, 13:48:46 schrieb Herbert Xu: Hi Herbert, > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan Mueller wrote: > > +static int crypto_kw_decrypt(struct aead_request *req) > > +{ > > + struct crypto_aead *aead = crypto_aead_reqtfm(req); > &g

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Mittwoch, 22. April 2015, 14:23:04 schrieb Stephan Mueller: Hi, > Am Mittwoch, 22. April 2015, 14:13:54 schrieb Herbert Xu: > > Hi Herbert, > > > On Wed, Apr 22, 2015 at 01:53:24PM +0800, Herbert Xu wrote: > > > On Wed, Apr 22, 2015 at 06:36:59AM +0200, Stephan

[PATCH 5/6] crypto: drbg - use Jitter RNG to obtain seed

d-off-by: Stephan Mueller --- crypto/drbg.c | 44 ++-- include/crypto/drbg.h | 1 + 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index cdc23c8..c98941a 100644 --- a/crypto/drbg.c +++ b/crypto/d

[PATCH 1/6] random: Addition of kernel_pool

arris Signed-off-by: Stephan Mueller --- drivers/char/random.c | 52 ++- 1 file changed, 39 insertions(+), 13 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 9cd6968..2868754 100644 --- a/drivers/char/random.c +++ b/drivers

[PATCH 0/6] Seeding DRBG with more entropy

.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] https://lkml.org/lkml/2014/4/27/174 [3] http://comments.gmane.org/gmane.linux.kernel/1701117 [4] http://www.chronox.de/jent.html Stephan Mueller (6): random: Addition of kernel_pool random: Async and sync API for accessing kernel

[PATCH 3/6] crypto: drbg - prepare for async seeding

for the initial seeding operation as well as by the asynchronous seeding call. The memory must be zeroized every time the DRBG seeding call succeeds to avoid entropy data lingering in memory. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/d

[PATCH 6/6] crypto: add jitterentropy RNG

kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kc

[PATCH 4/6] crypto: drbg - add async seeding operation

actual seeding of the DRBG. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/drbg.c | 46 ++ include/crypto/drbg.h | 1 + 2 files changed, 47 insertions(+) diff --git a/crypto/drbg.c b/c

[PATCH 2/6] random: Async and sync API for accessing kernel_pool

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. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- drivers/char/random.c

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Donnerstag, 23. April 2015, 09:39:28 schrieb Herbert Xu: Hi Herbert, > On Wed, Apr 22, 2015 at 02:44:08PM +0200, Stephan Mueller wrote: > > > Where does this 8-byte alignment requirement come from? > > > > Well, I am accessing the data in 8-byte chunks. Moreover, in

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Donnerstag, 23. April 2015, 09:33:37 schrieb Herbert Xu: Hi Herbert, > On Wed, Apr 22, 2015 at 02:23:04PM +0200, Stephan Mueller wrote: > > Isn't it a basic assumption to ablkcipher is that the ciphertext is equal > > in size as the plaintext? > > Not necessar

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu: Hi Herbert, > On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote: > > The KW does not return an IV. The IV is used for encryption to stir the > > encryption a bit. The resulting ciphertext now contains

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Donnerstag, 23. April 2015, 09:46:09 schrieb Herbert Xu: Hi Herbert, > On Thu, Apr 23, 2015 at 03:39:11AM +0200, Stephan Mueller wrote: > > The KW does not return an IV. The IV is used for encryption to stir the > > encryption a bit. The resulting ciphertext now contains

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Donnerstag, 23. April 2015, 10:55:58 schrieb Herbert Xu: Hi Herbert, > On Thu, Apr 23, 2015 at 04:51:56AM +0200, Stephan Mueller wrote: > > Encrypt input: IV, plaintext > > > > Encrypt output: processed IV, ciphertext > > > > Decrypt input: processed IV,

Re: [PATCH 6/6] crypto: add jitterentropy RNG

Am Donnerstag, 23. April 2015, 16:05:08 schrieb Paul Bolle: Hi Paul, > A nit only, I'm afraid: this patch adds a license mismatch. > > On Wed, 2015-04-22 at 21:25 +0200, Stephan Mueller wrote: > > --- /dev/null > > +++ b/crypto/jitterentr

Re: [PATCH 6/6] crypto: add jitterentropy RNG

Am Donnerstag, 23. April 2015, 16:18:31 schrieb Paul Bolle: Hi Paul, > On Thu, 2015-04-23 at 16:08 +0200, Stephan Mueller wrote: > > Other patches that are in the kernel that I wrote (e.g. > > the crypto/drbg.c) have the same license as above, but use > > MODULE_LICENSE(&

Re: [PATCH] crypto: add key wrapping block chaining mode

Am Freitag, 24. April 2015, 07:21:05 schrieb Herbert Xu: Hi Herbert, >On Thu, Apr 23, 2015 at 03:42:19PM +0200, Stephan Mueller wrote: >> Now, shall I kind of re-implement the chainiv ablkcipher wrapper into an IV >> handler that just helps my code? That will be a lot of co

[PATCH v2 6/6] crypto: add jitterentropy RNG

kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kc

[PATCH v2 5/6] crypto: drbg - use Jitter RNG to obtain seed

d-off-by: Stephan Mueller --- crypto/drbg.c | 46 -- include/crypto/drbg.h | 1 + 2 files changed, 41 insertions(+), 6 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 13dd626..fe081e1 100644 --- a/crypto/drbg.c +++ b/crypto/d

[PATCH v2 4/6] crypto: drbg - add async seeding operation

actual seeding of the DRBG. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/drbg.c | 46 ++ include/crypto/drbg.h | 1 + 2 files changed, 47 insertions(+) diff --git a/crypto/drbg.c b/c

[PATCH v2 3/6] crypto: drbg - prepare for async seeding

for the initial seeding operation as well as by the asynchronous seeding call. The memory must be zeroized every time the DRBG seeding call succeeds to avoid entropy data lingering in memory. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/d

[PATCH v2 0/6] Seeding DRBG with more entropy

http://comments.gmane.org/gmane.linux.kernel/1701117 [4] http://www.chronox.de/jent.html Stephan Mueller (6): random: Addition of kernel_pool random: Async and sync API for accessing kernel_pool crypto: drbg - prepare for async seeding crypto: drbg - add async seeding operation crypto: drbg - use Jitte

[PATCH v2 1/6] random: Addition of kernel_pool

arris Signed-off-by: Stephan Mueller --- drivers/char/random.c | 52 ++- 1 file changed, 39 insertions(+), 13 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 9cd6968..2868754 100644 --- a/drivers/char/random.c +++ b/drivers

[PATCH v2 2/6] random: Async and sync API for accessing kernel_pool

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. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- drivers/char/random.c

[PATCH v2] SP800-38F / RFC3394 key wrapping

. * Drop the support for user provided IV to initialize encrypt or for performing the verify step during decrypt. Stephan Mueller (1): crypto: add key wrapping block chaining mode crypto/Kconfig | 7 + crypto/Makefile | 1 + crypto/keywrap.c | 502

[PATCH v2] crypto: add key wrapping block chaining mode

bytes. Testing with CAVS test vectors for AES 128, 192, 256 in encryption and decryption up to 4096 bytes plaintext has been conducted successfully. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 7 + crypto/Makefile | 1 + crypto/keywrap.c | 502

Re: [PATCH v2 1/6] random: Addition of kernel_pool

Am Montag, 27. April 2015, 14:56:09 schrieb Herbert Xu: Hi Herbert, >On Sat, Apr 25, 2015 at 05:40:41PM +0200, Stephan Mueller wrote: >> +if (p->entropy_count <= >> +p->poolinfo->poolfracbits / 4) {

Re: [PATCH v2] crypto: add key wrapping block chaining mode

Am Montag, 27. April 2015, 16:26:07 schrieb Herbert Xu: Hi Herbert, >On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote: >> +/* >> + * Point to the end of the scatterlists to walk them backwards. >> + */ >> +

Re: [PATCH v2] crypto: add key wrapping block chaining mode

Am Montag, 27. April 2015, 16:29:35 schrieb Herbert Xu: Hi Herbert, >On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote: >> This patch implements the AES key wrapping as specified in >> NIST SP800-38F and RFC3394. > >This is my attempt at turning kw into a gi

Re: [BUG/PATCH] kernel RNG and its secrets

Am Freitag, 10. April 2015, 16:50:22 schrieb Stephan Mueller: Hi Stephan, >Am Freitag, 10. April 2015, 16:46:04 schrieb Daniel Borkmann: > >Hi Daniel, > >>On 04/10/2015 04:36 PM, Stephan Mueller wrote: >>> Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Fre

Re: [BUG/PATCH] kernel RNG and its secrets

Am Montag, 27. April 2015, 22:34:30 schrieb Daniel Borkmann: Hi Daniel, > On 04/27/2015 09:10 PM, Stephan Mueller wrote: > ... > > > I posted the issue on the clang mailing list on April 10 -- no word so > > far. I would interpret this as a sign that it is a no-is

Re: [PATCH v2] crypto: add key wrapping block chaining mode

Am Dienstag, 28. April 2015, 09:10:47 schrieb Herbert Xu: Hi Herbert, > On Mon, Apr 27, 2015 at 04:34:19PM +0200, Stephan Mueller wrote: > > Why do you think that will not work? I thought that the code works when > > the > > non-linear scatterlists are at least broken

Re: [PATCH v2] SP800-38F / RFC3394 key wrapping

Am Dienstag, 28. April 2015, 09:09:41 schrieb Herbert Xu: Hi Herbert, > On Sun, Apr 26, 2015 at 12:07:31AM +0200, Stephan Mueller wrote: > > Hi, > > > > Please note that this patch will conflict with the DRBG patch for > > additional seeding sent earlier toda

[PATCH v3 6/6] crypto: add jitterentropy RNG

kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kc

[PATCH v3 5/6] crypto: drbg - use Jitter RNG to obtain seed

d-off-by: Stephan Mueller --- crypto/drbg.c | 46 -- include/crypto/drbg.h | 1 + 2 files changed, 41 insertions(+), 6 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 13dd626..fe081e1 100644 --- a/crypto/drbg.c +++ b/crypto/d

[PATCH v3 4/6] crypto: drbg - add async seeding operation

actual seeding of the DRBG. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/drbg.c | 46 ++ include/crypto/drbg.h | 1 + 2 files changed, 47 insertions(+) diff --git a/crypto/drbg.c b/c

[PATCH v3 1/6] random: Addition of kernel_pool

arris Signed-off-by: Stephan Mueller --- drivers/char/random.c | 52 ++- 1 file changed, 39 insertions(+), 13 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 9cd6968..0b139dc 100644 --- a/drivers/char/random.c +++ b/drivers

Re: [PATCH v2] SP800-38F / RFC3394 key wrapping

Am Dienstag, 28. April 2015, 10:54:02 schrieb Herbert Xu: Hi Herbert, > On Tue, Apr 28, 2015 at 04:45:17AM +0200, Stephan Mueller wrote: > > The use case I see goes along the lines of dm-crypt and Ext4 crypto, or > > ecryptfs: > > > > For the key wrapping they

[PATCH v3 0/6] Seeding DRBG with more entropy

s not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] https://lkml.org/lkml/2014/4/27/174 [3] http://comments.gmane.org/gmane.linux.kernel/1701117 [4] http://www.chronox.de/jent.html Stephan Muell

[PATCH v3 3/6] crypto: drbg - prepare for async seeding

for the initial seeding operation as well as by the asynchronous seeding call. The memory must be zeroized every time the DRBG seeding call succeeds to avoid entropy data lingering in memory. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/d

[PATCH v3 2/6] random: Async and sync API for accessing kernel_pool

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. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- drivers/char/random.c

Re: [PATCH crypto-2.6] lib: make memzero_explicit more robust against dead store elimination

> 0x004004f0 <+0>: xorps %xmm0,%xmm0 > 0x004004f3 <+3>: movaps %xmm0,-0x18(%rsp) > 0x004004f8 <+8>: movl $0x0,-0x8(%rsp) > 0x00400500 <+16>: lea-0x18(%rsp),%rax > 0x00400505 <+21>: xor%eax,%eax >

Re: sha1_mb broken

Am Freitag, 26. August 2016, 03:15:06 CEST schrieb Stephan Mueller: Hi Megha, > Hi, > > I tried to execute tests with sha1_mb. Have you had a chance to look into this one? > > The execution simply stalls when invoking a digest operation -- i.e. the > digest operation does

Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo: Hi Kalle, > Stephan Mueller wrote: > > The ATH9K driver implements an RNG which is completely bypassing the > > standard Linux HW generator logic. > > > > The RNG may or may not deliver entropy. C

Re: sha1_mb broken

Am Mittwoch, 28. September 2016, 11:25:47 CEST schrieb Megha Dey: Hi Megha, > Hi Stephan, > > There was a bug fix: Commit ID : 0851561d (introduced in 4.6-rc5). I use the current cryptodev-2.6 tree. > > Assuming that you are using an older kernel than this one, maybe we are > issuing the compl

Re: sha1_mb broken

Am Mittwoch, 28. September 2016, 22:52:46 CEST schrieb Dey, Megha: Hi Megha, see a self contained example code attached. Ciao Stephan sha1_mb.tar.xz Description: application/xz-compressed-tar

Re: [PATCH 1/1] crypto: atmel-aes: add support to the XTS mode

Am Donnerstag, 29. September 2016, 18:49:07 CEST schrieb Cyrille Pitchen: Hi Cyrille, > This patch adds the xts(aes) algorithm, which is supported from > hardware version 0x500 and above (sama5d2x). > > Signed-off-by: Cyrille Pitchen > --- > drivers/crypto/atmel-aes-regs.h | 4 + > drivers/c

Re: Moving from blkcipher to skcipher

Am Montag, 3. Oktober 2016, 10:06:23 CEST schrieb Alex Cope: Hi Alex, > I'm currently working on implementing HEH encryption, and am in the > process of switching from the blkcipher interface to the skcipher > interface. All the examples I have found that use skcipher are > wrapping another mode

Re: Moving from blkcipher to skcipher

another > block cipher mode of operation. See gcm.c with the implementation referenced with crypto_gcm_base_tmpl or crypto_gcm_tmpl -- it uses the aead API which is conceptually similar to the skcipher API. And again you see the same concept applied as in the example I provided below. > >

Re: sha1_mb broken

Am Dienstag, 4. Oktober 2016, 00:25:07 CEST schrieb Dey, Megha: Hi Megha, > > > Hi Stephan, > > > > Your test code initialized the completion structure incorrectly, that led > > to the missing completion from being received. The init_completion call > > should be made before the crypto_ahash_di

Re: sha1_mb broken

Am Dienstag, 4. Oktober 2016, 09:08:42 CEST schrieb Tim Chen: Hi Tim, > There is a spin lock protecting the completion's wait_queue on the processes > waiting for the completion of the job, and the queue head. My suspicion is > if these structures are not initialized properly, we fail to look up

Re: chacha counters in random.c

Am Sonntag, 9. Oktober 2016, 20:16:27 CEST schrieb Sami Farin: Hi Sami, > commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a > > + chacha20_block(&crng->state[0], out); > + if (crng->state[12] == 0) > + crng->state[13]++; > > Did you mean > + if (++crng->state[12] =

Re: [PATCH 3/6] crypto: ccp - Add support for RSA on the CCP

Am Donnerstag, 13. Oktober 2016, 09:53:09 CEST schrieb Gary R Hook: Hi Gary, > Wire up the v3 CCP as a cipher provider. > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/Makefile |1 > drivers/crypto/ccp/ccp-crypto-main.c | 15 ++ > drivers/crypto/ccp/ccp-crypto-rsa.c |

Re: [PATCH 3/6] crypto: ccp - Add support for RSA on the CCP

Am Donnerstag, 13. Oktober 2016, 15:08:41 CEST schrieb Gary R Hook: Hi Gary, > On 10/13/2016 01:25 PM, Stephan Mueller wrote: > > Am Donnerstag, 13. Oktober 2016, 09:53:09 CEST schrieb Gary R Hook: > > > > Hi Gary, > > > >> Wire up the v3 CCP as a ciphe

Re: [PATCH 6/6] Add support for AEAD algos.

Am Donnerstag, 13. Oktober 2016, 16:39:39 CEST schrieb Harsh Jain: Hi Harsh, > Add support for following AEAD algos. > GCM,CCM,RFC4106,RFC4309,authenc(hmac(shaXXX),cbc(aes)). > > Signed-off-by: Harsh Jain > --- > drivers/crypto/chelsio/Kconfig |1 + > drivers/crypto/chelsio/chcr_alg

SPHINX: no structured comments

Hi, I am converting the kernel crypto API DocBook into Sphinx. The conversion is complete, but I am having difficulties finding the cause for the following notification obtained during the Sphinx compilation: ./include/linux/crypto.h:1: warning: no structured comments found I am unsure what is

Re: SPHINX: no structured comments

Am Samstag, 15. Oktober 2016, 18:12:36 CEST schrieb Markus Heiser: Hi Markus, > I suppose you have a typo in one of your kernel-doc > directives. E.g.:: > > .. kernel-doc:: include/linux/crypto.h > > :functions: fooTypo > > will produce those error messages: > > $ ./scripts/kernel-doc

[PATCH 2/7] crypto: doc - remove crypto API DocBook

With the conversion of the documentation to Sphinx, the old DocBook is now stale. Signed-off-by: Stephan Mueller --- Documentation/DocBook/Makefile|2 +- Documentation/DocBook/crypto-API.tmpl | 2092 - 2 files changed, 1 insertion(+), 2093 deletions

[PATCH 0/7] Conversion crypto API documentation to Sphinx

crypto API documentation is found at [1]. [1] http://www.chronox.de/crypto-API/index.html Stephan Mueller (7): crypto: doc - convert crypto API documentation to Sphinx crypto: doc - remove crypto API DocBook crypto: doc - fix source comments for Sphinx crypto: doc - fix separation of cipher

[PATCH 1/7] crypto: doc - convert crypto API documentation to Sphinx

With the conversion of the kernel crypto API DocBook to Sphinx, the monolithic document is broken up into individual documents. The documentation is unchanged with the exception of a slight reordering to keep the individual document parts self-contained. Signed-off-by: Stephan Mueller

[PATCH 6/7] crypto: doc - remove crypto_alloc_ablkcipher

Remove the documentation reference to crypto_alloc_ablkcipher as the API function call was removed. Signed-off-by: Stephan Mueller --- Documentation/crypto/api-skcipher.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api

[PATCH 5/7] crypto: doc - add KPP documentation

Add the KPP API documentation to the kernel crypto API Sphinx documentation. This addition includes the documentation of the ECDH and DH helpers which are needed to create the approrpiate input data for the crypto_kpp_set_secret function. Signed-off-by: Stephan Mueller --- Documentation/crypto

[PATCH 3/7] crypto: doc - fix source comments for Sphinx

Update comments to avoid any complaints from Sphinx during compilation. Signed-off-by: Stephan Mueller --- include/crypto/aead.h | 14 +++--- include/crypto/hash.h | 2 +- include/crypto/skcipher.h | 4 ++-- include/linux/crypto.h| 4 ++-- 4 files changed, 12 insertions

<    1   2   3   4   5   6   7   8   9   10   >