Re: Add-in encryption module to Netscape

At  3:42 PM 4/20/96 -0500, Alex Strasheim wrote:
>The best answer for these sorts of problems (at least for those of you not
>constrained by ITAR) might be java form processing applets that use their
>own crypto routines to submit the data.

I have thought about the sources of entropy available to a Java applet, and
there aren't many.  You should design your protocol so entropy is not
needed on the applet side.  Entropy is normally used to pick symmetric
encryption keys, and Initialization vectors


------------------------------------------------------------------------
Bill Frantz       | The CDA means  | Periwinkle  --  Computer Consulting
(408)356-8506     | lost jobs and  | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA

> I have thought about the sources of entropy available to a Java applet, and
> there aren't many.  You should design your protocol so entropy is not
> needed on the applet side.  Entropy is normally used to pick symmetric
> encryption keys, and Initialization vectors

This is a reasonable approach if you're just going to send information 
from the applet to the server, which is what we were talking about.  But 
if we want to use java applets for secure two way communications, aren't 
we going to need to find some entropy somewhere?

Is it feasible to make an input package that stores up entropy from
keyboard and mouse events as an applet is used?  Then when entropy is
needed, whatever's available is used.  If there's not enough a scribble
window or text field could pop up and the user could generate the rest. 
(This isn't my idea, I'm inferring it from something Hal wrote.)

And over the long run, what, if anything, could Sun do to let applets have
access to more entropy in Java?  Would it be practical to have an entropy
source in the api, that could be combined with other sources in the 
applet?