Right now, all new ZIP drivers are adapted to crypto_acomp APIs rather
than legacy crypto_comp APIs. Tradiontal ZIP drivers like lz4,lzo etc
have been also wrapped into acomp via scomp backend. But zswap.c is still
using the old APIs. That means zswap won't be able to work on any new
ZIP drivers in
Hi,
This patch set adds the required checks to make all aspects of
(EC)DH compliant with SP800-56A rev 3 assuming that all keys
are ephemeral. The use of static keys adds yet additional
validations which are hard to achieve in the kernel.
SP800-56A rev 3 mandates various checks:
- validation of
SP800-56A rev3 section 5.7.1.2 step 2 mandates that the validity of the
calculated shared secret is verified before the data is returned to the
caller. Thus, the export function and the validity check functions are
reversed. In addition, the sensitive variables of priv and rand_z are
zeroized.
Sig
After the generation of a local public key, SP800-56A rev 3 section
5.6.2.1.3 mandates a validation of that key with a full validation
compliant to section 5.6.2.3.1.
Only if the full validation passes, the key is allowed to be used.
Signed-off-by: Stephan Mueller
---
crypto/dh.c | 59 +
SP800-56A rev3 section 5.7.1.1 step 2 mandates that the validity of the
calculated shared secret is verified before the data is returned to the
caller. This patch adds the validation check.
Signed-off-by: Stephan Mueller
---
crypto/dh.c | 29 +
1 file changed, 29 inse
Add mpi_sub_ui() based on Gnu MP mpz_sub_ui() from mpz/aors_ui.h
adapting the code to the kernel's structures and coding style and also
removing the defines used to produce mpz_sub_ui() and mpz_add_ui()
from the same code.
Signed-off-by: Marcelo Henrique Cerri
Signed-off-by: Stephan Mueller
---
After the generation of a local public key, SP800-56A rev 3 section
5.6.2.1.3 mandates a validation of that key with a full validation
compliant to section 5.6.2.3.3.
Only if the full validation passes, the key is allowed to be used.
The patch adds the full key validation compliant to 5.6.2.3.3 a
On Sun, Jul 12, 2020 at 06:39:26PM +0200, Stephan Müller wrote:
> SP800-56A rev3 section 5.7.1.2 step 2 mandates that the validity of the
> calculated shared secret is verified before the data is returned to the
> caller. Thus, the export function and the validity check functions are
> reversed. In
Stephan,
On Sun, Jul 12, 2020 at 06:42:14PM +0200, Stephan Müller wrote:
> After the generation of a local public key, SP800-56A rev 3 section
> 5.6.2.1.3 mandates a validation of that key with a full validation
> compliant to section 5.6.2.3.3.
>
> Only if the full validation passes, the key is
At the top this file, we have:
#define pr_fmt(fmt) "chcr:" fmt
So there is no need to repeat "chcr : " in some error message when the
pr_xxx macro is used.
This would lead to log "chcr:chcr : blabla"
Signed-off-by: Christophe JAILLET
---
drivers/crypto/chelsio/chcr_algo.c | 19 +-
The error handling path of 'chcr_authenc_setkey()' is the same as this
error handling code.
So just 'goto out' as done everywhere in the function to simplify the code.
Signed-off-by: Christophe JAILLET
---
drivers/crypto/chelsio/chcr_algo.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(
A tag object represents the metadata (or simply a header/configuration)
and the actual data (e.g. black key) obtained from hardware.
Add functionality to tag an object with metadata:
- validate metadata: check tag object header;
- retrieve metadata: get tag object header configuration, black key
co
Tagged keys are keys that contain metadata indicating what
they are and how to handle them using tag_object API.
Add support, for tagged keys, to skcipher algorithms by
adding new transformations, with _tk_ prefix to distinguish
between plaintext and tagged keys.
For job descriptors a new option
Tagged keys are keys that contain metadata indicating what
they are and how to handle them using the new added tag_object API.
A tag object represents the metadata (or simply a header/configuration)
and the actual data (e.g. black key) obtained from hardware.
Patch #2 adds support, for tagged keys,
On 2020/7/10 21:12, Marcelo Henrique Cerri wrote:
Hi, Tianjia.
On Thu, Jul 09, 2020 at 04:40:09PM +0800, Tianjia Zhang wrote:
Expand the mpi library based on libgcrypt, and the ECC algorithm of
mpi based on libgcrypt requires these functions.
Some other algorithms will be developed based on
Am Sonntag, 12. Juli 2020, 20:06:13 CEST schrieb Vitaly Chikunov:
Hi Vitaly,
> Stephan,
>
> On Sun, Jul 12, 2020 at 06:42:14PM +0200, Stephan Müller wrote:
> > After the generation of a local public key, SP800-56A rev 3 section
> > 5.6.2.1.3 mandates a validation of that key with a full validati
On Mon, Jul 13, 2020 at 07:04:39AM +0200, Stephan Mueller wrote:
> Am Sonntag, 12. Juli 2020, 20:06:13 CEST schrieb Vitaly Chikunov:
>
> Hi Vitaly,
>
> > Stephan,
> >
> > On Sun, Jul 12, 2020 at 06:42:14PM +0200, Stephan Müller wrote:
> > > After the generation of a local public key, SP800-56A r
Am Montag, 13. Juli 2020, 07:59:50 CEST schrieb Vitaly Chikunov:
Hi Vitaly,
> > > > +/* SP800-56A section 5.6.2.3.3 full verification */
> > >
> > > Btw, 5.6.2.3.3 is partial validation, 5.6.2.3.2 is full validation
> > > routine.
> >
> > Looking at SP800-56A revision 3 from April 2018 I see:
>
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
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 LFSR.
Only if all three values are non-z
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: "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
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_
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
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,
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.
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
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
31 matches
Mail list logo
