42495e0317
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... |
||
---|---|---|
.. | ||
lib | ||
Makefile | ||
Makefile.rumpkerncomp |