summaryrefslogtreecommitdiffstats
path: root/crypto/lz4.c
diff options
context:
space:
mode:
authorStephan Mueller <smueller@chronox.de>2014-07-06 02:25:36 +0200
committerHerbert Xu <herbert@gondor.apana.org.au>2014-07-08 21:18:25 +0800
commit27e4de2bd1804c24e3e517dd54026c1f60e8fe27 (patch)
tree4f392026252cb1f1fb0a94a84204e424b0001b65 /crypto/lz4.c
parent4f150718797ffd539ace231d001eb41b09e13895 (diff)
downloadop-kernel-dev-27e4de2bd1804c24e3e517dd54026c1f60e8fe27.zip
op-kernel-dev-27e4de2bd1804c24e3e517dd54026c1f60e8fe27.tar.gz
crypto: drbg - Mix a time stamp into DRBG state
The current locking approach of the DRBG tries to keep the protected code paths very minimal. It is therefore possible that two threads query one DRBG instance at the same time. When thread A requests random numbers, a shadow copy of the DRBG state is created upon which the request for A is processed. After finishing the state for A's request is merged back into the DRBG state. If now thread B requests random numbers from the same DRBG after the request for thread A is received, but before A's shadow state is merged back, the random numbers for B will be identical to the ones for A. Please note that the time window is very small for this scenario. To prevent that there is even a theoretical chance for thread A and B having the same DRBG state, the current time stamp is provided as additional information string for each new request. The addition of the time stamp as additional information string implies that now all generate functions must be capable to process a linked list with additional information strings instead of a scalar. CC: Rafael Aquini <aquini@redhat.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/lz4.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud