Am 15.12.2012 20:15, schrieb Ondřej Bílka:
Why not use nonblocking pool and seed nonblocking pool only with half of
collected entropy to get /dev/random in almost all practical scenarios
nonblocking?
I would not recommend changing /dev/urandom. First, we would change the
characteristic of a ke
Am 16.12.2012 01:30, schrieb Theodore Ts'o:
On Fri, Dec 14, 2012 at 06:36:41PM +0100, Stephan Mueller wrote:
That patch is about one week from a mainline merge, btw.
Initially I was also thinking about get_random_int. But stack protection
depends on non-predictable numbers to ensure it cannot b
Hi,
in unregular intervals, I see the following crash. This crash happens if I
start a test run that executes a large number of scripts sequentially. It
happens with vanilla kernels from kernel.org and Fedora kernels. If my memory
serves me well, I saw the first types of these crashes with 4.11
Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala:
Hi srikanth,
> Hi Stephan,
>
> On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
> > Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
> >
> > Hi Srikanth,
> >
In case the kernel crypto API is not compiled, use ChaCha20 stream
cipher as DRNG. The LRNG ChaCha20 support provides the DRNG
implementation with the generate and update functions.
Th DRNG implements enhanced backward secrecy by re-creating the
entire internal state after generating random number
Add LRNG compilation support.
Signed-off-by: Stephan Mueller
---
drivers/char/Kconfig | 10 ++
drivers/char/Makefile | 10 +-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 31adbeb..ee26190 100644
--- a/drivers/ch
Hi,
The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as in virtual en
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
---
crypto/drbg.c | 11 +--
include/crypto/drbg.h | 7 +++
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/crypto/drbg.
When selecting the LRNG for compilation, disable the legacy /dev/random
implementation.
The LRNG is a drop-in replacement for the legacy /dev/random which
implements the same in-kernel and user space API. Only the hooks of
/dev/random into other parts of the kernel need to be disabled.
Signed-off
The LRNG with the following properties:
* noise source: interrupts timing with fast boot time seeding
* lockless LFSR to collect raw entropy
* use of kernel crypto API DRBG
* in case kernel crypto API is not compiled, use standalone
ChaCha20 based RNG
* used cipher types for hashes and DRBG
Am Montag, 15. Mai 2017, 12:52:11 CEST schrieb Julia Lawall:
Hi Julia,
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
Thank you, included -- it will be present in the next release.
Ciao
Stephan
ast case.
>
> julia
>
> -- Forwarded message --
> Date: Mon, 15 May 2017 14:09:39 +0800
> From: kbuild test robot
> To: kbu...@01.org
> Cc: Julia Lawall
> Subject: Re: [PATCH v11 4/5] LRNG - enable compile
>
> CC: kbuild-...@01.org
> In-Reply-To:
Am Dienstag, 12. Dezember 2017, 14:59:21 CET schrieb Jonathan Cameron:
Hi Jonathan,
> On Fri, 8 Dec 2017 13:43:20 +0100
>
> Stephan Mueller wrote:
> > Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron:
> >
> > Hi Jonathan,
> >
> > > As a heads up, the other nasties we've fou
Hi,
Changes v3:
* port to 4.15-rc8
* small code cleanups (isolation of type casts to functions pertaining
to the Apple Magic Trackpad 2
* clean up all checkpatch.pl errors and warnings (except those
where the patch uses the structure of existing code fragments)
* updated horizontal and vertica
Hi,
I am working on the user space library providing a wrapper to the AF_ALG user
space interface [1]. The AF_ALG interface supports asynchronous operation
which is utilized with the io_* system calls, including io_submit. All works
as expected.
The syscall io_submit sends data to the kernel a
Am Sonntag, 8. April 2018, 13:18:06 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
>
> Running syz-repro utility on this log, I think I've found the guilty guy:
> https://gist.githubusercontent.com/dvyukov/1dd75d55efd238e7207af1cc38478b3a/
> raw/403859b56b161a6fbb158e8953fac5bb6e73b1a1/gistfile1.txt
>
Hi,
May I ask to check whether this patch fixes the issue? I cannot re-create
the issue with the reproducter. Yet, as far as I understand, you try to
induce errors which shall validate whether the error code paths are correct.
The fix below should ensure this now.
Thanks a lot.
---8<---
>From
Am Sonntag, 8. April 2018, 17:41:17 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
>
> Hi,
>
> Here is config and kernel commit:
> https://groups.google.com/d/msg/syzkaller-bugs/PINYyzoaG1s/ntZPOZdcCAAJ
> You can also find compiler and image here if necessary:
> https://github.com/google/syzkaller/blob/
Hi Dimitry,
This fix prevents the kernel from crashing when injecting the fault.
Stack traces are yet shown but I guess that is expected every time
a fault is injected.
As to why KASAN did not notice this one, I am not sure. Maybe it is
because I use two buffer pointers to point to (almost) the
Sorry, this time with the proper subject line.
---8<---
During freeing of the internal buffers used by the DRBG, set the pointer
to NULL. It is possible that the context with the freed buffers is
reused. In case of an error during initialization where the pointers
do not yet point to allocated me
Add the Fixes, CC stable tags.
---8<---
During freeing of the internal buffers used by the DRBG, set the pointer
to NULL. It is possible that the context with the freed buffers is
reused. In case of an error during initialization where the pointers
do not yet point to allocated memory, the NULL v
Am Sonntag, 8. Juli 2018, 22:44:00 CEST schrieb Christoph Hellwig:
Hi Christoph,
>
> diff --git a/include/uapi/linux/aio_abi.h b/include/uapi/linux/aio_abi.h
> index 75846164290e..b7705ad66d78 100644
> --- a/include/uapi/linux/aio_abi.h
> +++ b/include/uapi/linux/aio_abi.h
> @@ -29,7 +29,11 @@
>
Am Sonntag, 8. Juli 2018, 22:44:00 CEST schrieb Christoph Hellwig:
Hi Christoph,
>
> diff --git a/include/uapi/linux/aio_abi.h b/include/uapi/linux/aio_abi.h
> index 75846164290e..b7705ad66d78 100644
> --- a/include/uapi/linux/aio_abi.h
> +++ b/include/uapi/linux/aio_abi.h
> @@ -29,7 +29,11 @@
>
Am Sonntag, 6. Januar 2019, 14:36:08 CET schrieb Vitaly Chikunov:
Hi Vitaly,
> Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
> 34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
> 2018 the CIS countries) cryptographic standard algorithms (called GOST
> algori
The Jitter RNG fast noise source implemented as part of the kernel
crypto API is queried for 256 bits of entropy at the time the seed
buffer managed by the LRNG is about to be filled.
CC: Torsten Duwe
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. T
In order to improve NUMA-locality when serving getrandom(2) requests,
allocate one DRNG instance per node.
The DRNG instance that is present right from the start of the kernel is
reused as the first per-NUMA-node DRNG. For all remaining online NUMA
nodes a new DRNG instance is allocated.
During b
The LRNG switchable DRNG support also allows the replacement of the hash
implementation used as conditioning component. The common generic hash
support code provides the required callbacks using the synchronous hash
implementations of the kernel crypto API.
All synchronous hash implementations sup
Parts of the LRNG are already covered by self-tests, including:
* Self-test of SP800-90A DRBG provided by the Linux kernel crypto API.
* Self-test of the PRNG provided by the Linux kernel crypto API.
* Raw noise source data testing including SP800-90B compliant
tests when enabling CONFIG_LRNG_
Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is
implemented.
The DRBG uses the kernel crypto API DRBG implementation. In addition, it
uses the kernel crypto API SHASH support to provide the hashing
operation.
The DRBG supports the choice of either a CTR DRBG using AES-256,
Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.
This allows using of the kernel crypto API PR
Implement health tests for LRNG's slow noise sources as mandated by
SP-800-90B The file contains the following health tests:
- stuck test: The stuck test calculates the first, second and third
discrete derivative of the time stamp to be processed by the hash
for the per-CPU entropy pool. Only
The DRNG switch support allows replacing the DRNG mechanism of the
LRNG. The switching support rests on the interface definition of
include/linux/lrng.h. A new DRNG is implemented by filling in the
interface defined in this header file.
In addition to the DRNG, the extension also has to provide a
Hi,
The following patch set provides a different approach to /dev/random which
is called Linux Random Number Generator (LRNG) to collect entropy within
the Linux kernel. It provides the same API and ABI and can be used as a
drop-in replacement.
The LRNG implements at least all features of the exi
In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compli
The test interface allows a privileged process to capture the raw
unconditioned noise that is collected by the LRNG for statistical
analysis. Such testing allows the analysis how much entropy
the interrupt noise source provides on a given platform.
Extracted noise data is not used to seed the LRNG.
To support the LRNG operation which uses the Jitter RNG separately
from the kernel crypto API, at a time where potentially the regular
memory management is not yet initialized, the Jitter RNG needs to
provide a state whose memory is defined at compile time. As only once
instance will ever be needed
This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.
CC: Torsten Duwe
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Tarreau
CC: Matthew Garrett
CC: Vito Caputo
CC: Andreas
The LRNG sysctl interface provides the same controls as the existing
/dev/random implementation. These sysctls behave identically and are
implemented identically. The goal is to allow a possible merge of the
existing /dev/random implementation with this implementation which
implies that this patch
Parts of the LRNG are already covered by self-tests, including:
* Self-test of SP800-90A DRBG provided by the Linux kernel crypto API.
* Self-test of the PRNG provided by the Linux kernel crypto API.
* Raw noise source data testing including SP800-90B compliant
tests when enabling CONFIG_LRNG_
Add runtime-pluggable support for all PRNGs that are accessible via
the kernel crypto API, including hardware PRNGs. The PRNG is selected
with the module parameter drng_name where the name must be one that the
kernel crypto API can resolve into an RNG.
This allows using of the kernel crypto API PR
This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Tarreau
CC: Matthew Garrett
CC: Vito Caputo
CC: Andreas Dilger
CC: Jan Ka
The test interface allows a privileged process to capture the raw
unconditioned noise that is collected by the LRNG for statistical
analysis. Such testing allows the analysis how much entropy
the interrupt noise source provides on a given platform.
Extracted noise data is not used to seed the LRNG.
To support the LRNG operation which uses the Jitter RNG separately
from the kernel crypto API, at a time where potentially the regular
memory management is not yet initialized, the Jitter RNG needs to
provide a state whose memory is defined at compile time. As only once
instance will ever be needed
The Jitter RNG fast noise source implemented as part of the kernel
crypto API is queried for 256 bits of entropy at the time the seed
buffer managed by the LRNG is about to be filled.
CC: "Eric W. Biederman"
CC: "Alexander E. Patrakov"
CC: "Ahmed S. Darwish"
CC: "Theodore Y. Ts'o"
CC: Willy Ta
Hi,
The following patch set provides a different approach to /dev/random which is
called Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the existing /dev/random is to provide
sufficient entropy during boot time as well as in virtu
In order to improve NUMA-locality when serving getrandom(2) requests,
allocate one DRNG instance per node.
The DRNG instance that is present right from the start of the kernel is
reused as the first per-NUMA-node DRNG. For all remaining online NUMA
nodes a new DRNG instance is allocated.
During b
In an effort to provide a flexible implementation for a random number
generator that also delivers entropy during early boot time, allows
replacement of the deterministic random number generation mechanism,
implement the various components in separate code for easier
maintenance, and provide compli
The DRNG switch support allows replacing the DRNG mechanism of the
LRNG. The switching support rests on the interface definition of
include/linux/lrng.h. A new DRNG is implemented by filling in the
interface defined in this header file.
In addition to the DRNG, the extension also has to provide a
Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is
implemented.
The DRBG uses the kernel crypto API DRBG implementation. In addition, it
uses the kernel crypto API SHASH support to provide the hashing
operation.
The DRBG supports the choice of either a CTR DRBG using AES-256,
Implement health tests for LRNG's slow noise sources as mandated by
SP-800-90B The file contains the following health tests:
- stuck test: The stuck test calculates the first, second and third
discrete derivative of the time stamp to be processed by the LFSR.
Only if all three values are non-z
The LRNG sysctl interface provides the same controls as the existing
/dev/random implementation. These sysctls behave identically and are
implemented identically. The goal is to allow a possible merge of the
existing /dev/random implementation with this implementation which
implies that this patch
Am Donnerstag, 20. August 2020, 14:07:40 CEST schrieb kernel test robot:
Hi,
>
> All warnings (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_drbg.c:226:1: warning: 'static' is not at
> >> beginning of declaration [-Wold-style-declaration]
> 226 | const static struct lrng_crypto_cb l
Am Donnerstag, 20. August 2020, 13:46:49 CEST schrieb kernel test robot:
Hi,
> All warnings (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_interfaces.c:120:6: warning: no previous prototype
> >> for 'add_hwgenerator_randomness' [-Wmissing-prototypes]
> 120 | void add_hwgenerator_rand
Am Donnerstag, 17. Dezember 2020, 04:07:30 CET schrieb yumeng:
Hi yumeng,
>
> I see in "SEC 2: Recommended Elliptic Curve Domain ParametersVersion2.0"
> that 'Recommend Elliptic Curve Domain Parameters over Fp' are secp192,
> secp224, secp256, secp384, and secp521, secp128 and secp320 are not
>
As the kernel crypto API implements HKDF, replace the
file-system-specific HKDF implementation with the generic HKDF
implementation.
Signed-off-by: Stephan Mueller
---
fs/crypto/Kconfig | 2 +-
fs/crypto/fscrypt_private.h | 4 +-
fs/crypto/hkdf.c| 108 +-
RFC5869 specifies an extract and expand two-step key derivation
function. The HKDF implementation is provided as a service function that
operates on a caller-provided HMAC cipher handle. The caller has to
allocate the HMAC cipher and then can invoke the HKDF service functions.
The HKDF implementati
The kernel crypto API provides the SP800-108 counter KDF implementation.
Thus, the separate implementation provided as part of the keys subsystem
can be replaced with calls to the KDF offered by the kernel crypto API.
The keys subsystem uses the counter KDF with a hash cipher primitive.
Thus, it o
Hi,
The key derviation functions are considered to be a cryptographic
operation. As cryptographic operations are provided via the kernel
crypto API, this patch set consolidates the KDF implementations into the
crypto API.
The KDF implementations are provided as service functions. Yet, the
interfa
SP800-108 defines three KDFs - this patch provides the counter KDF
implementation.
The KDF is implemented as a service function where the caller has to
maintain the hash / HMAC state. Apart from this hash/HMAC state, no
additional state is required to be maintained by either the caller or
the KDF
As a preparation to add the key derivation implementations, the
self-test data structure definition and the common test code is made
available.
The test framework follows the testing applied by the NIST CAVP test
approach.
The structure of the test code follows the implementations found in
crypto
As the kernel crypto API implements HKDF, replace the
file-system-specific HKDF implementation with the generic HKDF
implementation.
Signed-off-by: Stephan Mueller
---
fs/crypto/Kconfig | 2 +-
fs/crypto/hkdf.c | 98 +--
2 files changed, 20 insertion
The kernel crypto API provides the SP800-108 counter KDF implementation.
Thus, the separate implementation provided as part of the keys subsystem
can be replaced with calls to the KDF offered by the kernel crypto API.
The keys subsystem uses the counter KDF with a hash primitive. Thus,
it only use
As a preparation to add the key derivation implementations, the
self-test data structure definition and the common test code is made
available.
The test framework follows the testing applied by the NIST CAVP test
approach.
The structure of the test code follows the implementations found in
crypto
SP800-108 defines three KDFs - this patch provides the counter KDF
implementation.
The KDF is implemented as a service function where the caller has to
maintain the hash / HMAC state. Apart from this hash/HMAC state, no
additional state is required to be maintained by either the caller or
the KDF
RFC5869 specifies an extract and expand two-step key derivation
function. The HKDF implementation is provided as a service function that
operates on a caller-provided HMAC handle. The caller has to allocate
the HMAC shash handle and then can invoke the HKDF service functions.
The HKDF implementatio
Hi,
The key derviation functions are considered to be a cryptographic
operation. As cryptographic operations are provided via the kernel
crypto API, this patch set consolidates the KDF implementations into the
crypto API.
The KDF implementations are provided as service functions. Yet, the
interfa
Remove the specific code that adds a zero padding that was intended
to be invoked when the DH operation result was smaller than the
modulus. However, this cannot occur any more these days because the
function mpi_write_to_sgl is used in the code path that calculates the
shared secret in dh_compute_
The clearing of the OKM memory buffer in case of an error is already
performed by the HKDF implementation crypto_hkdf_expand. Thus, the
code clearing is not needed any more in the file system code base.
Signed-off-by: Stephan Mueller
---
fs/crypto/hkdf.c | 9 +++--
1 file changed, 3 insertio
Am Sonntag, 24. Januar 2021, 15:23:29 CET schrieb Ard Biesheuvel:
Hi Ard,
> On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
> > Hi,
> >
> > The key derviation functions are considered to be a cryptographic
> > operation. As cryptographic operations are provide
Am Sonntag, 24. Januar 2021, 15:32:59 CET schrieb Ard Biesheuvel:
Hi Ard,
> On Sun, 24 Jan 2021 at 15:23, Ard Biesheuvel wrote:
> > On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
> > > Hi,
> > >
> > > The key derviation functions are considered to be
Delete old userspace-only versions (8+8 bit). Instead expose the kernel-space
definitions (12+20 bit).
Signed-off-by: Stephan Mueller
---
Browsing some code I found that user-space and kernel-space macros for
(un-)packing major/minor device numbers differ. The user-space ones using still
the o
Am 14.09.2014 19:46, schrieb Greg KH:
> On Sun, Sep 14, 2014 at 07:35:28PM +0200, Stephan Müller wrote:
>> Delete old userspace-only versions (8+8 bit). Instead expose the kernel-space
>> definitions (12+20 bit).
>>
>> Signed-off-by: Stephan Mueller
>> ---
>
Enable testing of the SP800-108 and RFC5869 KDFs.
Signed-off-by: Stephan Mueller
---
crypto/tcrypt.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index e7fb87e114a5..5606e59e80ec 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -2054,6 +2054,
The HMAC-based Extract-and-Expand Key Derivation Function is conformant
to RFC5869.
The extraction phase can be invoked separately from the expansion phase.
This implies that the once a key is set and thus the extraction phase was
applied, the expansion phase can be invoked multiple times.
The HK
The SP800-108 compliant Key Derivation Function provides three KDF
types which are all implemented, including the counter-based KDF,
the double-pipeline KDF and the feedback KDF.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-by: Stephan Mueller
---
cr
Add known answer tests to the testmgr for the HKDF (RFC5869) cipher.
The known answer tests are derived from RFC 5869 appendix A.
Note, the HKDF is considered to be a FIPS 140-2 allowed (not approved)
cipher as of now. Yet, an allowed cipher is usable under FIPS 140-2
rules.
Signed-off-by: Steph
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 219 +++
crypto/testmgr.h | 107 +++
2 files changed, 326 insertions(+)
diff --git a/crypto/testmgr.c b/cry
Changes v2:
* Incorporation of all comments from Eric Biggers
Stephan Mueller (6):
crypto: add template handling for RNGs
crypto: kdf - SP800-108 Key Derivation Function
crypto: kdf - add known answer tests
crypto: hkdf - HMAC-based Extract-and-Expand KDF
crypto: hkdf - add known answer
Adds ability to register templates for pseudo random number generators
(PRNG). PRNGs are "meta" mechanisms using raw cipher primitives. Thus,
PRNGs can now be implemented as templates to allow the complete
flexibility the kernel crypto API provides.
The RNG API provides access to the PRNG algorith
Am Samstag, 12. Januar 2019, 10:55:35 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 11, 2019 at 09:12:54PM -0800, Eric Biggers wrote:
> > Hi Stephan,
> >
> > On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote:
> > > The RFC5869 compliant Key Derivat
Am Samstag, 12. Januar 2019, 06:19:15 CET schrieb Eric Biggers:
Hi Eric,
[...]
>
> > + }
> > + }
> > + }, {
> > + .alg = "hkdf(hmac(sha224))",
> > + .test = alg_test_null,
> > + .fips_allowed = 1,
>
> I think it is dumb to add algorith
Am Samstag, 12. Januar 2019, 06:26:46 CET schrieb Eric Biggers:
Hi Eric,
[...]
Thanks. I integrated updates for all comments.
Ciao
Stephan
Am Samstag, 12. Januar 2019, 06:12:54 CET schrieb Eric Biggers:
Hi Eric,
[...]
> > The extract and expand phases use different instances of the underlying
> > keyed message digest cipher to ensure that while the extraction phase
> > generates a new key for the expansion phase, the cipher for the
Am Samstag, 12. Januar 2019, 06:27:59 CET schrieb Eric Biggers:
Hi Eric,
[...]
> >
> > +obj-$(CONFIG_CRYPTO_KDF) += kdf.o
>
> This naming is too generic. CONFIG_CRYPTO_KDF and kdf.c imply that this is
> related to all KDFs. But actually it is an implementation of a few specific
> KDFs. Can y
Enable testing of the SP800-108 and RFC5869 KDFs.
Signed-off-by: Stephan Mueller
---
crypto/tcrypt.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index e7fb87e114a5..5606e59e80ec 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -2054,6 +2054,
Add known answer tests to the testmgr for the HKDF (RFC5869) cipher.
The known answer tests are derived from RFC 5869 appendix A.
Note, the HKDF is considered to be a FIPS 140-2 allowed (not approved)
cipher as of now. Yet, an allowed cipher is usable under FIPS 140-2
rules.
Signed-off-by: Steph
Add 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
---
crypto/rng.c | 44 +
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 226 +++
crypto/testmgr.h | 110 +++
2 files changed, 336 insertions(+)
diff --git a/crypto/testmgr.c b/cry
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
All three KDF types specified in SP800-108 are implemented.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-
Hi Herbert, Eric,
key derivation functions behave like a random number generator requiring
a seed and can generate arbitrarily-sized bit sequences. As KDFs wrap
ciphers, the first patch adds template support for the RNG part of the
kernel crypto API. This allows the KDFs to be implemented as templ
The RFC5869 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
The extract and expand phases use different instances of the underlying
keyed message digest cipher to ensure that while the extraction phase
generates a
Am Freitag, 18. Mai 2018, 10:36:04 CEST schrieb Geert Uytterhoeven:
Hi Geert,
>
> I tried following the code path, but couldn't find where it went wrong.
>
> mutex_lock(&drbg->drbg_mutex) is called from drbg_instantiate(), which is
> inlined by the compiler into drbg_kcapi_seed().
>
> Do you ha
Am Dienstag, 17. Januar 2017, 23:12:50 CET schrieb Theodore Ts'o:
Hi Theodore,
> On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote:
> > The random_ready callback mechanism is intended to replicate the
> > getrandom system call behavior to in-kernel users. As the
Am Montag, 9. Januar 2017, 19:24:12 CET schrieb Cyrille Pitchen:
Hi Cyrille,
> >> +static int atmel_aes_authenc_copy_assoc(struct aead_request *req)
> >> +{
> >> + size_t buflen, assoclen = req->assoclen;
> >> + off_t skip = 0;
> >> + u8 buf[256];
> >> +
> >> + while (assoclen) {
> >> +
Am Donnerstag, 22. Dezember 2016, 17:38:00 CET schrieb Cyrille Pitchen:
Hi Cyrille,
> This patchs allows to combine the AES and SHA hardware accelerators on
> some Atmel SoCs. Doing so, AES blocks are only written to/read from the
> AES hardware. Those blocks are also transferred from the AES to
Hi Ted,
with the removal of the nonblocking_pool, several code paths are now unused
which were only applicable to the nonblocking pool. This patch set removes
these unused code paths.
Also, a code path in the add_interrupt_randomness function that is never used
is removed.
In addition, the FIPS
The urandom_init_wait wait queue is a left over from the pre-ChaCha20
times and can therefore be savely removed.
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8e5ab20..482531d 100644
The variable random_min_urandom_seed is not needed any more as it
defined the reseeding behavior of the nonblocking pool. Though it is not
needed any more, it is left in the code for user space interface
compatibility.
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 4 +---
1 file cha
>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001
From: Stephan Mueller
Date: Thu, 15 Dec 2016 12:42:33 +0100
Subject:
The function maybe_reseed_primary_crng is not used anywhere and thus can
be removed. Besides, it contains the check crng_init > 2 which will
never become t
The random_ready callback mechanism is intended to replicate the
getrandom system call behavior to in-kernel users. As the getrandom
system call unblocks with crng_init == 1, trigger the random_ready
wakeup call at the same time.
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 1 +
1
1 - 100 of 261 matches
Mail list logo
