I spent some time looking at the web pages. In answer to Perry's questions:
At 6:11 PM -0700 5/19/99, Keith Dawson wrote:
[Some parts of this description make me nervous. Why are PRIVATE keys
being stored on a server, for instance?
Because you can't store data on a user's machine from a Java applet. IMHO,
signed applets, which can kind of access the user's disk, are a technology
whose time is not yet. There are currently 3 different signing models, the
Netscape model, the Microsoft model, and the Javasoft model. (Macintosh
Runtime for Java (MRJ) implements the Javasoft model and is used by
MSIE/Mac on System 8.5. I don't know anyone who has succeeded in
distributing a signed applet using the Javasoft model.)
The web pages are very up front in saying that the security of the system
is critically dependent on the passphrase. I agree.
Why use SSL to send keys when
you could use SSL to just send the data?
Then the server would have access to the plaintext. Ideally, the applet
would generate the symmetric keys and encrypt them with the public key of
the receivers. I can't remember the details of symmetric key generation,
but they are recommending SSL to avoid Trojan applets.
On the surface, the biggest danger in this system is having a TLA force
them to serve a Trojan applet to one or more clients and using that to
recover the passphrase. I have not looked at the (available) source, or
verified that the applet derives from that source.
Etc., etc... --Perry]
FYI, I just put up this piece as a Tasty Bit of the Day at
http://tbtf.com/#tbotoday .
___
1999-05-19:
..HushMail: free Web-based email with bulletproof encryption
Hush Communications has quietly begun beta testing a significant
development in email privacy. HushMail [1] works like Hotmail or
Rocketmail -- you can set up multiple free accounts and access them
from any Web browser anywhere -- but when you email another HushMail
user your communication is protected by unbreakable encryption. The
crypto, implemented in a downloadable Java applet, was developed
outside of US borders and so has no export limitations.
Here are the FAQ [2] and a more technical overview [3] of the Hush-
Mail system.
HushMail public and private keys are 1024 bits long, and are stored
on a server located in Canada. All information sent between the
HushApplet and the HushMail server is encrypted via the Blowfish
symmetric 128-bit algorithm. The key to this symmetric pipe is ran-
domly generated each session by the server and is transferred to the
client machine over a secure SSL connection.
When you sign on as a new user you can choose an anonymous account
or an identifiable one. For the latter you have to fill out a dem-
ographic profile, to make you more attractive (in the aggregate) to
HushMail's advertisers. The HushApplet walks you through generating
a public-private key-pair. The process is fun and slick as a smelt.
You need to come up with a secure pass-phrase, and in this process
HushMail gives only minimal guidance. You might want to visit Arnold
Reinhold's Diceware page [4], where he lays out a foolproof pass-
phrase protocol utilizing a pair of dice.
HushMail relies heavily on Java (JVM 1.1.5 or higher), so it can
only be used with the latest browsers. The earliest workable version
of Netscape's browser is 4.04, but some features don't work in
versions before 4.07; the latest version, 4.5, is best. For Internet
Explorer users, 4.5 is recommended, but the latest Windows release
of IE 4.0 (subversion 4.72.3110) works as well. Red Hat Linux
version 5.2 is also tested and supported. Unfortunately, HushMail
does not work on Macintoshes, due to limitations in Apple's Java
implementation. (Mac users can crawl HushMail under Connectix
Virtual PC. Note that I don't say "run." I've tried this
interpretation-under-emulation and do not recommend it.) The company
is trying urgently to connect with the right people at Apple to get
this situation remedied.
One of the limitations of this early release of HushMail is that en-
cryption can only be used to and from another HushMail account. It
is not currently possible to export your public/private key-pair, to
set up automatic forwarding of mail sent to a HushMail account, or
to import non-Hush public keys. I spoke with Cliff Baltzley, Hush's
CEO and chief technical wizard. He stresses that Hush's desire and
intention is to move toward interoperability with other players in
the crypto world, such as PGP and S/MIME. The obstacles to doing so
are the constraints on technical resources (read: offshore crypto
programmers) and legal questions of intellectual property. Baltzley
believes that HushMail's positive impact on privacy worldwide will
be enhanced by maximizing the product's openness.
