[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: randomness & perfect forward (or proactive?) secrecy
> >But, I ment the randomness samplying sw, not Photuris (or would it also be
> >part of Photuris?).
>
> Oh, sorry. As pointed out in the excellent Schiller/Eastlake/Crocker
> RFC, randomness sampling is inherently machine dependent. So it's a
> separate module in addition to my Photuris code. I'm working in a
> 486-type PC environment so it would probably have to be redone for
> other machines. But I'm willing to make my code available with those caveats
> once I'm happy with it.
Great, please keep us posted. Of course I agree that this code (as well as
NRP) are not a part of the key management protocol, they are just general
tools for getting randomness.
>
> Re merging Photuris: as I said during my talk to the WG, I was
> particularly interested in stimulating a discussion about the merits
> of the design philosophy. And I certainly seem to have succeeded in that!
> (I do hope it will eventually produce some sort of consensus, though...)
Agree.
>
> I still believe that a single protocol like Photuris, with the proper
> tuning knobs, can satisfy both the needs of those with strong security
> requirements and those with performance concerns. I haven't seen much
> discussion of this particular aspect; am I off base here?
I agree with this too, although I believe we'll still have multiple protocols
to support existing scenarios (e.g. enterprises already using Kerberos/DCE).
But we don't need more than one public key protocol with the right knobs
(maybe including one for non-interactivity as in SKIP).
Best, Amir
References: