Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH 3/4] crypto: drbg - replace spinlock with mutex
Date: Mon, 20 Apr 2015 02:45:02 +0200	[thread overview]
Message-ID: <2050637.ShmA9JvV53@tauon> (raw)
In-Reply-To: <20150420002709.GB16750@gondor.apana.org.au>

Am Montag, 20. April 2015, 08:27:09 schrieb Herbert Xu:

Hi Herbert,

>On Sun, Apr 19, 2015 at 05:37:21PM +0200, Stephan Mueller wrote:
>> I am not sure I understand you correctly: shall the DRBG have these
>> precautions? If so, wouldn't we break the requirements in SP800-90A where
>> the DRBG is intended to seed itself?
>> 
>> Or would you want to update the crypto_alloc_rng routine?
>
>No.  Our API doesn't provide the Instantiate_function obviously.
>If you really want to have an explicit instantiate function then
>you can provide a wrapper:
>
>crypto_instantiate_drbg(...)
>{
>	struct crypto_rng *drbg;
>
>	drbg = crypto_alloc_rng(...);
>	crypto_rng_reset(drbg, ...);
>	return drbg;
>}
>
>The fact that crypto_alloc_rng currently instantiates the RNG
>is wrong because there is no provision for the personalisation
>string.

I do not want to deviate from the kernel crypto API by adding some additional 
wrapper. But what we can do is to leave the DRBG unseeded during alloc time. 
As long as the DRBG is unseeded, it will return EAGAIN to any request for 
random numbers, forcing the caller to use crypto_rng_reset to activate the 
DRBG.

When the DRBG receives a reset, it will always obtain the seed and treat any 
user-provided data as personalization string / additional data.

Such change is straight forward. I would like to roll that one into the 
patchset for the discussed seeding revamp as this issue is definitely 
noticeable there. That patch set is already complete, I am just doing the 
final testing before airing it.

Ciao
Stephan

  reply	other threads:[~2015-04-20  0:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 12:53 [PATCH 0/4] crypto: drbg - revamp locking Stephan Mueller
2015-04-17 12:54 ` [PATCH 1/4] cryoto: drbg - clear all temporary memory Stephan Mueller
2015-04-18 10:59   ` Herbert Xu
2015-04-17 12:54 ` [PATCH 2/4] crypto: drbg - do not create shadow copy Stephan Mueller
2015-04-18 10:49   ` Herbert Xu
2015-04-18 12:51     ` Stephan Mueller
2015-04-17 12:55 ` [PATCH 3/4] crypto: drbg - replace spinlock with mutex Stephan Mueller
2015-04-18 10:55   ` Herbert Xu
2015-04-18 11:35     ` Stephan Mueller
2015-04-19  5:48       ` Herbert Xu
2015-04-19 15:37         ` Stephan Mueller
2015-04-20  0:27           ` Herbert Xu
2015-04-20  0:45             ` Stephan Mueller [this message]
2015-04-20  0:48               ` Herbert Xu
2015-04-20  0:51                 ` Stephan Mueller
2015-04-17 12:56 ` [PATCH 4/4] crypto: drbg - leave cipher handles operational Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2050637.ShmA9JvV53@tauon \
    --to=smueller@chronox.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox