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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------