Re: Kernel RNG rework; when opencrypto really doesn't win
Matthias Drochner <[email protected]> Wed, 9 Nov 2011 20:51:35 +0100
| Newsgroups | gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.kernel,gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
[email protected] said: > > The mapping cprng_fast/strong to > > arc4random/nist_ctr could be controlled by some kernel defines, with the > > option to map both to arc4random > I don't particularly want to jam another layer of runtime indirection > in the middle. I wasn't thinking of runtime indirection. Just a build time option, let's name it "ARC4RANDOM_IS_OK", and then some #ifdefs where cprng_strong/fast are defined. The strong cprng code could then be pulled in with a !arc4random_is_ok condition in files.*, and the condition for rijndael would be OR'ed with a similar one. best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------