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
On Mon, Apr 20, 2015 at 02:45:02AM +0200, Stephan Mueller wrote:
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
Am Montag, 20. April 2015, 08:48:55 schrieb Herbert Xu:
Hi Herbert,
On Mon, Apr 20, 2015 at 02:45:02AM +0200, Stephan Mueller wrote:
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
Am Samstag, 18. April 2015, 18:55:23 schrieb Herbert Xu:
Hi Herbert,
Incidentally the whole reset concept seems redundant as you could
always free and allocate a new RNG instead. So I'm planning on
replacing it with a seed/reseed function instead. IOW it will
keep the existing state and
On Fri, Apr 17, 2015 at 02:55:28PM +0200, Stephan Mueller wrote:
@@ -1349,7 +1348,9 @@ static int drbg_generate_long(struct drbg_state *drbg,
unsigned int chunk = 0;
slice = ((buflen - len) / drbg_max_request_bytes(drbg));
chunk = slice ?
On Sat, Apr 18, 2015 at 01:35:40PM +0200, Stephan Mueller wrote:
When you do that, may I ask you to also update the crypto_alloc_rng. This
function has one major drawback at the moment: we are wasting precious
entropy. The testmgr must allocate the RNG for performing its testing using
The DRBG shall hold a long term lock. Therefore, the lock is changed to
a mutex which implies that the DRBG can only be used in process context.
The lock now guards the instantiation as well as the entire DRBG
generation operation. Therefore, multiple callers are fully serialized
when generating
