The DRBG test code implements the CAVS test approach.
As discussed for the test vectors, all DRBG types are covered with
testing. However, not every backend cipher is covered with testing. To
prevent the testmgr from logging missing testing, the NULL test is
registered for all backend ciphers not
All types of the DRBG (CTR, HMAC, Hash) are covered with test vectors.
In addition, all permutations of use cases of the DRBG are covered:
* with and without predition resistance
* with and without additional information string
* with and without personalization string
As
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled
at compile time. At least one DRBG type shall be selected.
The default is the HMAC DRBG as its code base is smallest.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 36 +++-
1 file change
Signed-off-by: Stephan Mueller
---
crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/Makefile b/crypto/Makefile
index 38e64231..bfa94fa 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rn
The header file includes the definition of:
* DRBG data structures with
- struct drbg_state as main structure
- struct drbg_core referencing the backend ciphers
- struct drbg_state_ops callbach handlers for specific code
supporting the Hash, HMAC, CTR DRBG impleme
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 predi
On Wednesday, May 28, 2014 at 07:01:52 AM, Amos Kong wrote:
> @@ -154,7 +154,7 @@ calibrate_xor_blocks(void)
> #undef xor_speed
>
> out:
> - free_pages((unsigned long)b1, 2);
> + free_pages((unsigned long)b1, 1);
>
> active_template = fastest;
> return 0;
I s
On Wednesday, May 28, 2014 at 12:01:09 PM, Corentin LABBE wrote:
> Hello
>
> I have a problem when using a simple md5 tfm.
> When I use the data that ahash_request_ctx() give me, it will cause random
> crash when removing the module later. I do not understand it, because
> .cra_ctxsize seems to be
On Tuesday, May 27, 2014 at 08:25:48 PM, Himangi Saraogi wrote:
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions. Also, linux/device.h is added to make sure the devm_*()
> routine declar
