Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
On Fri, May 30, 2014 at 12:08:08PM +0200, Stephan Mueller wrote: >> > We already have a user-space interface to change priorities. > > Great -- if I may ask, which interface is that? Take a look at crypto/crypto_user.c Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Am Freitag, 30. Mai 2014, 17:05:48 schrieb Herbert Xu: Hi Herbert, > On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote: > > A second aspect is the implementation of the stdrng. Currently, the > > offered > > patch does not include the stdrng selection. I am currently working on the > > completion of the addition of the stdrng selection to the offered patch. > > My > > idea is the following: currently, all DRBG types are registered with their > > own cra_name. However, there shall be one particular DRBG registered > > twice. When registering the instance again, the cra_name shall be > > "stdrng". In addition, if the kernel command line contains fips=1, the > > cra_priority of that stdrng should be set to 300. That implies that when > > the kernel resolves the stdrng, it resolves to get_random_bytes in normal > > mode, but to the stdrng DRBG in FIPS mode. > > Just have all of them register as stdrng with differing priorities. Will do. Just to clarify: I would use priorities below 200 if (!fips_enabled) and above 200 for fips_enabled. This would mean that per default, the get_random_bytes/krng has the highest priority in non-fips mode. In FIPS mode, the DRBGs would have the higher priority per default. > We already have a user-space interface to change priorities. Great -- if I may ask, which interface is that? > > Cheers, Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote: > > A second aspect is the implementation of the stdrng. Currently, the offered > patch does not include the stdrng selection. I am currently working on the > completion of the addition of the stdrng selection to the offered patch. My > idea is the following: currently, all DRBG types are registered with their > own > cra_name. However, there shall be one particular DRBG registered twice. When > registering the instance again, the cra_name shall be "stdrng". In addition, > if the kernel command line contains fips=1, the cra_priority of that stdrng > should be set to 300. That implies that when the kernel resolves the stdrng, > it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in > FIPS > mode. Just have all of them register as stdrng with differing priorities. We already have a user-space interface to change priorities. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote: A second aspect is the implementation of the stdrng. Currently, the offered patch does not include the stdrng selection. I am currently working on the completion of the addition of the stdrng selection to the offered patch. My idea is the following: currently, all DRBG types are registered with their own cra_name. However, there shall be one particular DRBG registered twice. When registering the instance again, the cra_name shall be stdrng. In addition, if the kernel command line contains fips=1, the cra_priority of that stdrng should be set to 300. That implies that when the kernel resolves the stdrng, it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in FIPS mode. Just have all of them register as stdrng with differing priorities. We already have a user-space interface to change priorities. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Am Freitag, 30. Mai 2014, 17:05:48 schrieb Herbert Xu: Hi Herbert, On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote: A second aspect is the implementation of the stdrng. Currently, the offered patch does not include the stdrng selection. I am currently working on the completion of the addition of the stdrng selection to the offered patch. My idea is the following: currently, all DRBG types are registered with their own cra_name. However, there shall be one particular DRBG registered twice. When registering the instance again, the cra_name shall be stdrng. In addition, if the kernel command line contains fips=1, the cra_priority of that stdrng should be set to 300. That implies that when the kernel resolves the stdrng, it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in FIPS mode. Just have all of them register as stdrng with differing priorities. Will do. Just to clarify: I would use priorities below 200 if (!fips_enabled) and above 200 for fips_enabled. This would mean that per default, the get_random_bytes/krng has the highest priority in non-fips mode. In FIPS mode, the DRBGs would have the higher priority per default. We already have a user-space interface to change priorities. Great -- if I may ask, which interface is that? Cheers, Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
On Fri, May 30, 2014 at 12:08:08PM +0200, Stephan Mueller wrote: We already have a user-space interface to change priorities. Great -- if I may ask, which interface is that? Take a look at crypto/crypto_user.c Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Am Samstag, 24. Mai 2014, 05:14:59 schrieb Herbert Xu:
Hi Herbert,
> Stephan Mueller wrote:
> > Hi,
> >
> > the following set of patches implements the deterministic random bit
> > generator (DRBG) specified by SP800-90A.
> >
> > The DRBG implementation offers the following:
> >* All three DRBG types are implemented with a derivation function.
> >* All DRBG types are available with and without prediction
> >resistance.
> >* All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available
> >
> > for the HMAC and Hash DRBGs.
> >
> >* All AES types of AES-128, AES-192 and AES-256 are available for
> >the
> >
> > CTR DRBG.
> >
> >* A self test is implemented with drbg_healthcheck().
> >* The FIPS 140-2 continuous self test is implemented.
> >* Additional cipher primitives, such as Serpent or Twofish, can be
> >
> > added to the DRBG without changing the implementation. The only
> > change necessary is to the DRBG definition given in the cores[]
> > array.
>
> Where is the code that actually uses this?
There are several answers to this.
First: as required by NIST SP800-131A, the ANSI X9.31 DRNG is considered to be
sunset by the end of 2015. The FIPS 140-2 validation part of NIST requires
that ANSI X9.31 DRNGs are not allowed for new validations since the start of
this year and prohibited for revalidations starting next year. The replacement
of ANSI X9.31 is SP800-90A.
The Linux kernel currently implements one DRNG in ansi_cprng.c. This DRNG is
an ANSI X9.31 DRNG. This means, the offered SP800-90A implementation can be
considered a replacement of ansi_cprng.c.
A second aspect is the implementation of the stdrng. Currently, the offered
patch does not include the stdrng selection. I am currently working on the
completion of the addition of the stdrng selection to the offered patch. My
idea is the following: currently, all DRBG types are registered with their own
cra_name. However, there shall be one particular DRBG registered twice. When
registering the instance again, the cra_name shall be "stdrng". In addition,
if the kernel command line contains fips=1, the cra_priority of that stdrng
should be set to 300. That implies that when the kernel resolves the stdrng,
it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in FIPS
mode.
Here some code snippet from my patch I am working on:
if (fips_stdrng) {
memcpy(alg->cra_name, "stdrng", 6);
...
if (fips_stdrng)
alg->cra_priority = 300;
else
alg->cra_priority = 100;
Ciao
Stephan
--
| Cui bono? |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Am Samstag, 24. Mai 2014, 05:14:59 schrieb Herbert Xu:
Hi Herbert,
Stephan Mueller smuel...@chronox.de wrote:
Hi,
the following set of patches implements the deterministic random bit
generator (DRBG) specified by SP800-90A.
The DRBG implementation offers the following:
* All three DRBG types are implemented with a derivation function.
* All DRBG types are available with and without prediction
resistance.
* All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available
for the HMAC and Hash DRBGs.
* All AES types of AES-128, AES-192 and AES-256 are available for
the
CTR DRBG.
* A self test is implemented with drbg_healthcheck().
* The FIPS 140-2 continuous self test is implemented.
* Additional cipher primitives, such as Serpent or Twofish, can be
added to the DRBG without changing the implementation. The only
change necessary is to the DRBG definition given in the cores[]
array.
Where is the code that actually uses this?
There are several answers to this.
First: as required by NIST SP800-131A, the ANSI X9.31 DRNG is considered to be
sunset by the end of 2015. The FIPS 140-2 validation part of NIST requires
that ANSI X9.31 DRNGs are not allowed for new validations since the start of
this year and prohibited for revalidations starting next year. The replacement
of ANSI X9.31 is SP800-90A.
The Linux kernel currently implements one DRNG in ansi_cprng.c. This DRNG is
an ANSI X9.31 DRNG. This means, the offered SP800-90A implementation can be
considered a replacement of ansi_cprng.c.
A second aspect is the implementation of the stdrng. Currently, the offered
patch does not include the stdrng selection. I am currently working on the
completion of the addition of the stdrng selection to the offered patch. My
idea is the following: currently, all DRBG types are registered with their own
cra_name. However, there shall be one particular DRBG registered twice. When
registering the instance again, the cra_name shall be stdrng. In addition,
if the kernel command line contains fips=1, the cra_priority of that stdrng
should be set to 300. That implies that when the kernel resolves the stdrng,
it resolves to get_random_bytes in normal mode, but to the stdrng DRBG in FIPS
mode.
Here some code snippet from my patch I am working on:
if (fips_stdrng) {
memcpy(alg-cra_name, stdrng, 6);
...
if (fips_stdrng)
alg-cra_priority = 300;
else
alg-cra_priority = 100;
Ciao
Stephan
--
| Cui bono? |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Stephan Mueller wrote: > Hi, > > the following set of patches implements the deterministic random bit generator > (DRBG) specified by SP800-90A. > > The DRBG implementation offers the following: > >* All three DRBG types are implemented with a derivation function. >* All DRBG types are available with and without prediction resistance. >* All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available > for the HMAC and Hash DRBGs. >* All AES types of AES-128, AES-192 and AES-256 are available for the > CTR DRBG. >* A self test is implemented with drbg_healthcheck(). >* The FIPS 140-2 continuous self test is implemented. >* Additional cipher primitives, such as Serpent or Twofish, can be > added to the DRBG without changing the implementation. The only > change necessary is to the DRBG definition given in the cores[] > array. Where is the code that actually uses this? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Stephan Mueller smuel...@chronox.de wrote: Hi, the following set of patches implements the deterministic random bit generator (DRBG) specified by SP800-90A. The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. * Additional cipher primitives, such as Serpent or Twofish, can be added to the DRBG without changing the implementation. The only change necessary is to the DRBG definition given in the cores[] array. Where is the code that actually uses this? Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Hi, the following set of patches implements the deterministic random bit generator (DRBG) specified by SP800-90A. The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. * Additional cipher primitives, such as Serpent or Twofish, can be added to the DRBG without changing the implementation. The only change necessary is to the DRBG definition given in the cores[] array. As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of this year for official uses, including FIPS 140-2 compliance. Additional tests including the CAVS test framework are available at [1]. [1] http://www.chronox.de/drbg.html Stephan Mueller (6): SP800-90A Deterministic Random Bit Generator header file for DRBG DRBG kernel configuration options compile the DRBG code DRBG testmgr test vectors Add DRBG test code to testmgr crypto/Kconfig| 36 +- crypto/Makefile |1 + crypto/drbg.c | 2005 + crypto/testmgr.c | 248 +++ crypto/testmgr.h | 843 + include/crypto/drbg.h | 291 +++ 6 files changed, 3442 insertions(+), 1 deletion(-) create mode 100644 crypto/drbg.c create mode 100644 include/crypto/drbg.h Changes v2: * Overhauling code structure for simpler code as suggested by Rafael Aquini: - each DRBG type exports only two crypto functions, - the individual DRBG implementations structure closely according to SP 800-90A, - using struct drbg_string to refer to buffers to avoid too many function parameters and prevent multiple data structure conversions - use inline more thoroughly - replace macros with small inline functions - remove unnecessary indirections - replace of large stack variables with a scratch buffer allocated at the beginning of DRBG operation -- see comments about scratchpad throughout the code * Revamping DRBG flags usage: flags are only intended to select the appropriate DRBG type and DRBG strength. Flags are not intended to be visible to external callers. * Adding comments throughout the code to refer to the appropriate steps documented in SP 800-90A. * Fix invocation of kernel crypto API hash * Fix coding style and apply scripts/checkpatch.pl * Change locking approach: only very small code sections are guarded by a lock. This implies that the entire DRBG operates on a shadow copy of the original DRBG state -- see comments for drbg_copy_drbg * Perform thorough testing: - Performing of a full scale CAVS test with CAVS interface available at http://www.chronox.de/drbg.html - Performing tests by obtaining data which is not a multiple of cipher block size and check it with the ent tool to ensure that the generation loop does not reuse stale buffers to avoid errors like CVE-2013-4345. Changes v3: * fix invocation of drbg_sec_strength to determine the amount of seed needed for the DRBG. The function returns information as a byte value, but the invoker assumed a bit value. * change default value returned by drbg_sec_strength to be the maximum entropy defined by SP800-90A to catch erroneous invocations of the function. * Fix invocaction of d_ops in drbg_generate: drbg->d_ops ==> shadow->d_ops * Make return of drbg_fips_continuous_test cleaner as suggested by Clemens Ladisch * Fix comments on how to invoke the DRBG at the beginning of the file drbg_ctr_df: replace the for loop for calculation of padlen that used to call up to 16 modulo operations with one modulo operation * drbg_ctr_df: replace plain integer values with sizeof() to make code clearer * drbg_hash_hashgen: replace memset() on drbg->scratchpad with memset() on src/dst pointers to make code clearer * as recommended by Peter Waltenberg: add re-invocation of self tests as required by 11.3.3 -- the tests are commented out because they make no mathematical sense. However, if a FIPS 140-2 validation requires these tests, the code just needs to be activated. * as recommended by Peter Waltenberg: add error path tests as required by 11.3.2 -- see new function of drbg_healthcheck_sanity * add debug printk * perform testing in FIPS 140-2 mode * as recommended by Peter Waltenberg: add drbg_generate_long to generate arbitrary long strings Changes v4: * change return codes of generate functions to signed int to convey error
[PATCH v7 0/6] SP800-90A Deterministic Random Bit Generator
Hi, the following set of patches implements the deterministic random bit generator (DRBG) specified by SP800-90A. The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. * Additional cipher primitives, such as Serpent or Twofish, can be added to the DRBG without changing the implementation. The only change necessary is to the DRBG definition given in the cores[] array. As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of this year for official uses, including FIPS 140-2 compliance. Additional tests including the CAVS test framework are available at [1]. [1] http://www.chronox.de/drbg.html Stephan Mueller (6): SP800-90A Deterministic Random Bit Generator header file for DRBG DRBG kernel configuration options compile the DRBG code DRBG testmgr test vectors Add DRBG test code to testmgr crypto/Kconfig| 36 +- crypto/Makefile |1 + crypto/drbg.c | 2005 + crypto/testmgr.c | 248 +++ crypto/testmgr.h | 843 + include/crypto/drbg.h | 291 +++ 6 files changed, 3442 insertions(+), 1 deletion(-) create mode 100644 crypto/drbg.c create mode 100644 include/crypto/drbg.h Changes v2: * Overhauling code structure for simpler code as suggested by Rafael Aquini: - each DRBG type exports only two crypto functions, - the individual DRBG implementations structure closely according to SP 800-90A, - using struct drbg_string to refer to buffers to avoid too many function parameters and prevent multiple data structure conversions - use inline more thoroughly - replace macros with small inline functions - remove unnecessary indirections - replace of large stack variables with a scratch buffer allocated at the beginning of DRBG operation -- see comments about scratchpad throughout the code * Revamping DRBG flags usage: flags are only intended to select the appropriate DRBG type and DRBG strength. Flags are not intended to be visible to external callers. * Adding comments throughout the code to refer to the appropriate steps documented in SP 800-90A. * Fix invocation of kernel crypto API hash * Fix coding style and apply scripts/checkpatch.pl * Change locking approach: only very small code sections are guarded by a lock. This implies that the entire DRBG operates on a shadow copy of the original DRBG state -- see comments for drbg_copy_drbg * Perform thorough testing: - Performing of a full scale CAVS test with CAVS interface available at http://www.chronox.de/drbg.html - Performing tests by obtaining data which is not a multiple of cipher block size and check it with the ent tool to ensure that the generation loop does not reuse stale buffers to avoid errors like CVE-2013-4345. Changes v3: * fix invocation of drbg_sec_strength to determine the amount of seed needed for the DRBG. The function returns information as a byte value, but the invoker assumed a bit value. * change default value returned by drbg_sec_strength to be the maximum entropy defined by SP800-90A to catch erroneous invocations of the function. * Fix invocaction of d_ops in drbg_generate: drbg-d_ops == shadow-d_ops * Make return of drbg_fips_continuous_test cleaner as suggested by Clemens Ladisch * Fix comments on how to invoke the DRBG at the beginning of the file drbg_ctr_df: replace the for loop for calculation of padlen that used to call up to 16 modulo operations with one modulo operation * drbg_ctr_df: replace plain integer values with sizeof() to make code clearer * drbg_hash_hashgen: replace memset() on drbg-scratchpad with memset() on src/dst pointers to make code clearer * as recommended by Peter Waltenberg: add re-invocation of self tests as required by 11.3.3 -- the tests are commented out because they make no mathematical sense. However, if a FIPS 140-2 validation requires these tests, the code just needs to be activated. * as recommended by Peter Waltenberg: add error path tests as required by 11.3.2 -- see new function of drbg_healthcheck_sanity * add debug printk * perform testing in FIPS 140-2 mode * as recommended by Peter Waltenberg: add drbg_generate_long to generate arbitrary long strings Changes v4: * change return codes of generate functions to signed int to convey error codes
