summaryrefslogtreecommitdiff
path: root/crypto/cast6_generic.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
commit5884c4a24f87112b71e3d7a67d37180a49435d9d (patch)
tree7f65529d27ddc512acedac7f6ffb601a4ddbe1fe /crypto/cast6_generic.c
parent2af71eb6a0c83c1331cb2e546bd598272dc3d305 (diff)
downloadlinux-crypto-5884c4a24f87112b71e3d7a67d37180a49435d9d.tar.gz
linux-crypto-5884c4a24f87112b71e3d7a67d37180a49435d9d.zip
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/cast6_generic.c')
0 files changed, 0 insertions, 0 deletions