yarrow/prng - option to bypass
hartmans at MIT.EDU
Thu Nov 19 13:48:11 EST 2009
>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:
Zhanna> On Nov 19, 2009, at 8:36 AM, Sam Hartman wrote:
Zhanna> Help me understand the mobile device use case? Is
Zhanna> there a specific mobile device you're thinking of? If so,
Zhanna> can you discuss details?
Zhanna> Taking into account the limitations of the
Zhanna> mob.dev/embedded systems in terms of memory, battery
Zhanna> capacity etc one should think if some modules may be
Zhanna> shared between various application sitting on the
Zhanna> device. It is a general approach and PRNG seems to be a
Zhanna> good candidate for this. Also, consider the case of prng
Zhanna> optimization. As for the question if I have a specific
Zhanna> device in mind the answer is no. Having said that, I
Zhanna> would like to point to the TeamF1 presentation @ KC
Zhanna> conference slide" Whats Different About Embedded
Zhanna> Kerberos?" that suggests that they do have proprietary
Zhanna> PRNG outside the native Kerberos. If appropriate, and if
Zhanna> secure and thread/fork safe, it could be used in place of
Zhanna> native Kerb yarrow /prng.
OK. This makes sense.
So what you are saying above argues much more for something at build
time than at run time. Also, what you're doing argues fairly strongly
for an interface that we expect vendors to replace.
So, I guess what I'd do here is develop an interface document
explaining what a vendor needed to do to plug in a new PRNG after
you're done making changes. I think that's the only additional
deliverable I'd recommend over what you initially started with.
More information about the krbdev