Adding Fortuna as a new prng

[Sam Hartman]

>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:
    Zhanna> 1. Code borrowing. At the moment we know about two open
    Zhanna> source implementations of Fortuna in C. One of them is from
    Zhanna> libTomCrypt project and another one circulates under
    Zhanna> "Copyright (c) Marko Kreen" license. The opinion was
    Zhanna> expressed that even though libTomCrypt license does not have
    Zhanna> any restrictions, it is somewhat faceless, and consequently
    Zhanna> might be an issue for the lawyers. So, perhaps, Marko
    Zhanna> Kreen's implementation is a better bid.

I don't understand this point.
Can you please post the license or a link to the license for the code
you plan to include.

    Zhanna> 2. Fortuna requires SHA256. At the moment SHA2 is not part
    Zhanna> of Kerberos crypto-system. If Kerberos is built with OpenSSL
    Zhanna> or NSS cryptography, is it OK to use crypto primitives from
    Zhanna> these providers to implement Fortuna and do not support
    Zhanna> Fortuna PRNG for the library built with the built-in crypto
    Zhanna> backend?

It seems that sha2 implementations are widely available.  I think if
you're going to ship a prng it should work with the built-in crypto
unless there's a compelling reason this is a bad idea.  Needing to pick
and import a sha2 implementation doesn't seem like one.

    Zhanna> 3. Fortuna and Yarrow living together. Some use-cases
    Zhanna> indicate that Kerberos library might show better performance
    Zhanna> if both PRNG implementations are available at run-time. (For
    Zhanna> example, some lightweight client shares libraries with the
    Zhanna> server: the former works faster with Yarrow, the latter -
    Zhanna> with Fortuna). So, Fortuna and Yarrow should co-exist and
    Zhanna> PRNG selection should be a configurable, and pluggable,
    Zhanna> feature. This is the plan for the future.  As the first step
    Zhanna> in Fortuna direction, however, we suggest to take an
    Zhanna> approach of one-PRNG-implementation-per-library.

I kind of question the future plan.  I consider myself a power user and
couldn't imagine ever wanting to switch PRNGs.  I think few Kerberos
users want the complexity of PRNG selection.  I've never had to select
the PRNG I use for OpenSSL, Windows, ssh, NSS or the like.  Why should I
for Kerberos?

--Sam