yarrow/prng - option to bypass

[Sam Hartman]

>>>>> "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" What’s 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.

--Sam