Re: [PATCH v2 1/2] crypto: jitter - replace LFSR with SHA3-256

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 10, 2023 at 10:55:13PM +0200, Stephan Müller wrote:
>
> +static int jent_kcapi_init(struct crypto_tfm *tfm)
> +{
> +	struct jitterentropy *rng = crypto_tfm_ctx(tfm);
> +	struct crypto_shash *hash;
> +	struct shash_desc *sdesc;
> +	int size, ret = 0;
> +
> +	/*
> +	 * Use SHA3-256 as conditioner. We allocate only the generic
> +	 * implementation as we are not interested in high-performance. The
> +	 * execution time of the SHA3 operation is measured and adds to the
> +	 * Jitter RNG's unpredictable behavior. If we have a slower hash
> +	 * implementation, the execution timing variations are larger. When
> +	 * using a fast implementation, we would need to call it more often
> +	 * as its variations are lower.
> +	 */
> +	hash = crypto_alloc_shash(JENT_CONDITIONING_HASH, 0, 0);
> +	if (IS_ERR(hash)) {
> +		pr_err("Cannot allocate conditioning digest\n");
> +		return PTR_ERR(hash);
> +	}
> +	rng->tfm = hash;
> +
> +	size = sizeof(struct shash_desc) + crypto_shash_descsize(hash);
> +	sdesc = kmalloc(size, GFP_KERNEL);
> +	if (!sdesc) {
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +
> +	sdesc->tfm = hash;
> +	crypto_shash_init(sdesc);
> +	rng->sdesc = sdesc;
> +
> +	rng->entropy_collector = jent_entropy_collector_alloc(1, 0, sdesc);
> +	if (!rng->entropy_collector)
> +		ret = -ENOMEM;

Is this supposed to fail or not?

> +
> +	spin_lock_init(&rng->jent_lock);
> +	return 0;
> +
> +err:
> +	jent_kcapi_cleanup(tfm);
> +	return ret;
> +}
> +

Thanks,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux