Skip to content
  • Harald Freudenberger's avatar
    ff98cc98
    s390/crypto: add arch_get_random_long() support · ff98cc98
    Harald Freudenberger authored
    
    
    The random longs to be pulled by arch_get_random_long() are
    prepared in an 4K buffer which is filled from the NIST 800-90
    compliant s390 drbg. By default the random long buffer is refilled
    256 times before the drbg itself needs a reseed. The reseed of the
    drbg is done with 32 bytes fetched from the high quality (but slow)
    trng which is assumed to deliver 100% entropy. So the 32 * 8 = 256
    bits of entropy are spread over 256 * 4KB = 1MB serving 131072
    arch_get_random_long() invocations before reseeded.
    
    How often the 4K random long buffer is refilled with the drbg
    before the drbg is reseeded can be adjusted. There is a module
    parameter 's390_arch_rnd_long_drbg_reseed' accessible via
      /sys/module/arch_random/parameters/rndlong_drbg_reseed
    or as kernel command line parameter
      arch_random.rndlong_drbg_reseed=<value>
    This parameter tells how often the drbg fills the 4K buffer before
    it is re-seeded by fresh entropy from the trng.
    A value of 16 results in reseeding the drbg at every 16 * 4 KB = 64
    KB with 32 bytes of fresh entropy pulled from the trng. So a value
    of 16 would result in 256 bits entropy per 64 KB.
    A value of 256 results in 1MB of drbg output before a reseed of the
    drbg is done. So this would spread the 256 bits of entropy among 1MB.
    Setting this parameter to 0 forces the reseed to take place every
    time the 4K buffer is depleted, so the entropy rises to 256 bits
    entropy per 4K or 0.5 bit entropy per arch_get_random_long().  With
    setting this parameter to negative values all this effort is
    disabled, arch_get_random long() returns false and thus indicating
    that the arch_get_random_long() feature is disabled at all.
    
    arch_get_random_long() is used by random.c among others to provide
    an initial hash value to be mixed with the entropy pool on every
    random data pull. For about 64 bytes read from /dev/urandom there
    is one call to arch_get_random_long(). So these additional random
    long values count for performance of /dev/urandom with measurable
    but low penalty.
    
    Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
    Reviewed-by: default avatarJuergen Christ <jchrist@linux.ibm.com>
    Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
    ff98cc98
    s390/crypto: add arch_get_random_long() support
    Harald Freudenberger authored
    
    
    The random longs to be pulled by arch_get_random_long() are
    prepared in an 4K buffer which is filled from the NIST 800-90
    compliant s390 drbg. By default the random long buffer is refilled
    256 times before the drbg itself needs a reseed. The reseed of the
    drbg is done with 32 bytes fetched from the high quality (but slow)
    trng which is assumed to deliver 100% entropy. So the 32 * 8 = 256
    bits of entropy are spread over 256 * 4KB = 1MB serving 131072
    arch_get_random_long() invocations before reseeded.
    
    How often the 4K random long buffer is refilled with the drbg
    before the drbg is reseeded can be adjusted. There is a module
    parameter 's390_arch_rnd_long_drbg_reseed' accessible via
      /sys/module/arch_random/parameters/rndlong_drbg_reseed
    or as kernel command line parameter
      arch_random.rndlong_drbg_reseed=<value>
    This parameter tells how often the drbg fills the 4K buffer before
    it is re-seeded by fresh entropy from the trng.
    A value of 16 results in reseeding the drbg at every 16 * 4 KB = 64
    KB with 32 bytes of fresh entropy pulled from the trng. So a value
    of 16 would result in 256 bits entropy per 64 KB.
    A value of 256 results in 1MB of drbg output before a reseed of the
    drbg is done. So this would spread the 256 bits of entropy among 1MB.
    Setting this parameter to 0 forces the reseed to take place every
    time the 4K buffer is depleted, so the entropy rises to 256 bits
    entropy per 4K or 0.5 bit entropy per arch_get_random_long().  With
    setting this parameter to negative values all this effort is
    disabled, arch_get_random long() returns false and thus indicating
    that the arch_get_random_long() feature is disabled at all.
    
    arch_get_random_long() is used by random.c among others to provide
    an initial hash value to be mixed with the entropy pool on every
    random data pull. For about 64 bytes read from /dev/urandom there
    is one call to arch_get_random_long(). So these additional random
    long values count for performance of /dev/urandom with measurable
    but low penalty.
    
    Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: default avatarIngo Franzki <ifranzki@linux.ibm.com>
    Reviewed-by: default avatarJuergen Christ <jchrist@linux.ibm.com>
    Signed-off-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Loading