Date: Thu, 2 Jul 1998 04:28:42 -0700 (PDT)
From: Marianne Mueller <Marianne.Mueller@Eng>
Subject: Re: Signer applet
To: java-security@java.Sun.COM
Resend due to ongoing mailer problems
------------- Begin Forwarded Message -------------
Date: Thu, 2 Jul 1998 03:16:21 -0700 (PDT)
From: Marianne Mueller <Marianne.Mueller@Eng.Sun.COM>
Subject: Re: Signer applet
To: java-security@web1.javasoft.com, rsodre@br.oracle.com
MIME-Version: 1.0
Content-MD5: tidrv7wjELIgW6t8xFyZbQ==
I guess I don't understand why you need to develop your own protocol (as it
were) for authentication. Why not use the standard signing? This gives
you two things: certainty about where the code came from, and, certainty
that the code was not modified. It doesn't get you confidentiality
(encrypted information) but it's not clear to me that that is a requirement
for you.
For information on digital signatures, refer to Bruce Schneier's book,
"Applied Cryptography." he discusses the general idea, and also discusses
some common algorithms. We are using DSA for digital signature.
> Date: Thu, 28 May 1998 10:25:16 -0300
> From: Rodrigo Sodre <rsodre@br.oracle.com>
> MIME-Version: 1.0
> To: java-security@web1.javasoft.com
> Subject: Signer applet
> Content-Transfer-Encoding: 7bit
>
> Greetings.
>
> We're developing an applet that must sign some data befote its storage
> in a databank. The client user fills some forms and then download a
> certified applet, already loaded with the data to be signed. Well, in
> this moment the private key must be used (it will be used DSA algorith
> and keys since it is already implemented) and we are considering two
> approaches:
>
> 1) The applet will generate the public/private key pair, ask the
> client to type a password to encrypt the private key (we will
> implement the cipher class since Sun's KeyStorage implementation
> uses a weak one), AND BOTH WOULD BE STORED IN THE DATABANK. When
> signing, THE APPLET WOULD BE ALREADY LOADED WITH THE DATA AND THE
> ENCRYPTED PRIVATE KEY. The user types its password, the private key
> is then decrypted, used for signing, and then discarded. When the
> server receives the signed form, it would retrive the public key
> and verify the signature. If OK, the form is stored, otherwise an
> error message would be shown to the user by the applet.
>
> 2) In the second approach, when generating the pair, ONLY THE PUBLIC
> KEY IS SENT AND THE PRIVATE KEY IS ENCRYPTED AND STORED IN A FILE
> IN THE USER MACHINE. When signing, THE APPLET WOULD REQUEST THIS
> FILE, ask the password and the following steps are the same.
>
> The first approach is far more easy to be used by the client user:
> he/she doesn't need to provide a file containing the private key, it can
> be used in any machine with a browser (and not only in the machines
> where the file would be stored), no special access rights must be given
> to the applet (the certificate is used only for authenticity).
>
> What seems strange to me is the private key remains with another entity,
> even encripted. But in both approaches the client is trusting the applet
> not to reveal the plain private key to anyone, so the first argument may
> not justify approach 2. I guess I'm excessive paranoic.
>
> Please send comments about these approaches, and other ones if possible.
>
>
>
> Thanks in advance and best regards.
>
> Rodrigo Sodre - rsodre@br.oracle.com
------------- End Forwarded Message -------------