At Wed, 16 Jun 1999 08:57:25 -0400, "Arnold G. Reinhold"
<[EMAIL PROTECTED]> wrote:
>The applet source is available from the HushMail site. I am not aware of
>any additional restrictions on a local applet or any way for HushMail to
>tell the difference. On the contrary, you could convert their source to a
>Java application and then be free of all Java "sandbox" restrictions. You
>would have to keep up with future changes HushMail makes in the applet tho.
Yes, I have succeeded in downloading the source, compiling it and then
running the applet under the appletviewer that comes with the Java
Development Kit. Using this I can connect to hushmail and read and
send mail; in fact, that is how I am sending this.
There are a few problems though:
- When you log into hushmail, it downloads to you a web page, using
SSL, which includes the <applet> tag and a bunch of parameters. (I
posted a sample yesterday.) Two of the parameters are different
every time you log in - a 64 bit random sessionID and a 128 bit
random sessionKey. When the applet connects to hushmail, it sends
the sessionID in the clear, and from then on all transmissions are
encrypted using the sessionKey as a Blowfish key in CBC mode. (It
doesn't use SSL for communicating with the server.)
Obviously the hushmail server is generating a new Blowfish key each
time a user logs in, which is used for the duration of the session.
This means that a rather elaborate system is necessary in order to
run the hushmail applet locally, in which you first log in and then
pull the sessionID and sessionKey out of the SSL stream, which you
then pass as parameters to the applet. It's not clear how to
automate this process.
- For some reason I haven't been able to run the applet from a local
disk using Netscape. It can't find the Connection class (one of
the classes used in the applet). It may be that my version of the
JDK is not compatible with my version of Netscape.
>The source code (1.03) confirms that HushMail does not use salt before
>hashing the passphrase. That is a serious weakness, as we have been
>discussing. Users can compensate by choosing a longer passphrase or by
>appending a unique non-secret value, e.g. their phone number or hushmail
>user name, to their pasphrase. The latter approach still means more typing,
>but not more memorizing.
>
>HushMail should fix this, perhaps by appending the user name to the
>passphrase automatically. This would eliminate the need to store the salt
>in their database. For backwards compatibility, the applet could simply try
>both ways (with and without an appended user name).
Given that your passphrase is the only thing that keeps the server
from knowing your private key, the system is relying very heavily on
users choosing good passphrases. While salt does help against
dictionary attacks, it is really important that no passphrases be in
anyone's dictionary anyway. If that is accomplished, salt doesn't
matter that much.
Another potential security problem I've noted in looking at the source
is that each message is separately encrypted with Blowfish in CBC, but
without carryover of the IV from message to message. Each message
gets its own IV, chosen from the Java util.random function, which is
seeded with the time of day in milliseconds. If two messages are sent
in the same millisecond, they will have the same IV. This leaks only
a tiny amount of information but it could be improved by having the IV
of each message be the last block of cyphertext from the previous
message.
--Hush
Get HushMail. The world's first free, fully encrypted, web-based email system.
Speak freely with HushMail.... http://www.hushmail.com
