[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment regarding draft-mcdonald-pf-key-v2-00.txt
> > Assuming the kernel is supposed to generate the IV, why not
> > allow the PF_KEY interface transfer an IV? It seems to me, if an
> > external hardware were available, random data would be best
> > obtained by a user level application rather than the kernel.
>
> I don't agree.
>
> 1) Assuming we're talking about UNIX-like systems
> (monolithic large kernel), I'm not sure this statement is
> really true.. especially given the work by Don Davis and others
> sampling randomness from disk drives and Ted Ts'o's
> /dev/random driver for linux (which also exports a
> kernel-internal API for kernel code which needs strong
> randomness).
>
Yes, a UNIX like system: Mach.
> 2) even if it were true, I don't think PF_KEY is the right place to
> put a "deliver random bitstream to kernel" interface. For any
> number of reasons, you really want a "pipe" of randomness, not a
> request-response protocol.
>
The reasons I think query/response is a reasonable
alternative are:
* I do not have source for my kernel (and not likely to ever get
it) thus probing interfaces and buffers is somewhat problematic.
Not having kernel source requires the operating system vendor
to implement a PF_KEY domain. I think this is a little too
ambitious and less likely to happen for legacy systems. Not
having source forces me to diverge from the spec. Perhaps a
reasonable alternative to creating a socket in the PF_KEY
domain is to open a device?
* One of my random data sources is an open mic indirectly
accessible via /dev. To use that device I have to implement some
mechanism to tell the kernel it (or another) may be available as
a random data source. Also, its interface is through a given API
not usable within the kernel.
-dpg
References: