![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / crypto / nist_ctr_drbg
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Mostly merge changes from HEAD upto 20200411
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1365): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #173): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away... XXX pullup-7 XXX pullup-8 XXX pullup-9
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (https://eprint.iacr.org/2018/349) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away... XXX pullup-7 XXX pullup-8 XXX pullup-9
Sync with HEAD
s/static inline/static __inline/g for consistency.
sync with head
file nist_ctr_aes_rijndael.h was added on branch yamt-pagecache on 2012-04-17 00:07:23 +0000
First step of random number subsystem rework described in <20111022023242.BA26F14A158@mail.netbsd.org>. This change includes the following: An initial cleanup and minor reorganization of the entropy pool code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are fixed. Some effort is made to accumulate entropy more quickly at boot time. A generic interface, "rndsink", is added, for stream generators to request that they be re-keyed with good quality entropy from the pool as soon as it is available. The arc4random()/arc4randbytes() implementation in libkern is adjusted to use the rndsink interface for rekeying, which helps address the problem of low-quality keys at boot time. An implementation of the FIPS 140-2 statistical tests for random number generator quality is provided (libkern/rngtest.c). This is based on Greg Rose's implementation from Qualcomm. A new random stream generator, nist_ctr_drbg, is provided. It is based on an implementation of the NIST SP800-90 CTR_DRBG by Henric Jungheim. This generator users AES in a modified counter mode to generate a backtracking-resistant random stream. An abstraction layer, "cprng", is provided for in-kernel consumers of randomness. The arc4random/arc4randbytes API is deprecated for in-kernel use. It is replaced by "cprng_strong". The current cprng_fast implementation wraps the existing arc4random implementation. The current cprng_strong implementation wraps the new CTR_DRBG implementation. Both interfaces are rekeyed from the entropy pool automatically at intervals justifiable from best current cryptographic practice. In some quick tests, cprng_fast() is about the same speed as the old arc4randbytes(), and cprng_strong() is about 20% faster than rnd_extract_data(). Performance is expected to improve. The AES code in src/crypto/rijndael is no longer an optional kernel component, as it is required by cprng_strong, which is not an optional kernel component. The entropy pool output is subjected to the rngtest tests at startup time; if it fails, the system will reboot. There is approximately a 3/10000 chance of a false positive from these tests. Entropy pool _input_ from hardware random numbers is subjected to the rngtest tests at attach time, as well as the FIPS continuous-output test, to detect bad or stuck hardware RNGs; if any are detected, they are detached, but the system continues to run. A problem with rndctl(8) is fixed -- datastructures with pointers in arrays are no longer passed to userspace (this was not a security problem, but rather a major issue for compat32). A new kernel will require a new rndctl. The sysctl kern.arandom() and kern.urandom() nodes are hooked up to the new generators, but the /dev/*random pseudodevices are not, yet. Manual pages for the new kernel interfaces are forthcoming.