[EMAIL PROTECTED] wrote, Fri. 13, Dec 2002:

All of the "Secure Webmail" isn't secure because, the
message, the passphrase, and the secret key, are saved
in the server or travel on the server in not encrypted
form. Hush is a bit more secure because your
passphrase and message in clear form does not travel
in the server (client side java applet).

For good security level, we need to use PGP/GNUPG in
CLIENT SIDE.
-------
Seagold's computer guru responded to this post. Since this is kind of
long, I will post Seagold's Open Source Information (also displayed on
Seagold's web site) separately.

Happy Holidays to all,
Angela

"Strictly speaking, this is a correct criticism. It is not useful to
store the secret key on the server. Private keys MUST be kept secure
in order to have any value. For that matter, even storing one's
private key on one's own local hard drive isn't necessarily secure,
due to the danger of keystroke monitoring programs. Really, it
should be stored on a floppy disk or other removable media so that
even someone who obtained access to both the computer and the key
passphrase would be unable to decrypt anything without also being in
physical possession of the floppy.

For this reason Seagold does not utilize public key cryptography
(other than that built into the SSL browser connection utilizing the
site certificate). Passphrases, as utilized with conventional
cryptography, are not saved on the server. They "travel on the
server in not encrypted form" only in temporary memory, which is
freed as soon as the encryption/decryption step is performed. Note
that if the encrypt/decrypt step is performed locally (e.g. in a
client side java applet) you still have a similar problem: the clear
passphrase MUST exist, at least for a moment, in your computer's local
memory, as the encryption/decryption is performed. This represents an
improvement only to the extent that your computer's local RAM is
justly considered more secure than that of the server. Again, based on
the possibility of monitoring software, operating system backdoors,
etc., that may or may not be the case. The Seagold server is a pure
Debian Linux machine; most of the "client side" computers used by
customers are likely to be Microsoft-based systems running Internet
Explorer, equipped with Java plugins to enable applet processing. On
which platform would YOU prefer to store, even for a few microseconds,
your clear text encryption passphrase in system memory?

The Seagold software has been implemented with security in mind. For
example, when PGP or GPG are invoked to encrypt/decrypt a message
using a passphrase, the passphrase is transmitted only via a special
file descriptor created between the parent and child processes. It
is not, for example, attached to the child's command line or posted
into the child process's environment. Thus the passphrase only exists
in the stack memory of two temporary threads, and (even more briefly)
in the kernel data buffers. It would be extremely difficult (to say
the least) for monitoring software to locate such data even if in fact
such software were surreptitiously installed on the Seagold server on
Sealand.

All of which does not change the fact that the most secure email
message possible is the one which is never sent. If two Seagold
subscribers send each other a message, then it is never transmitted
over the internet at all (or at least, not as an email message per
se.) The sender uses an SSL browser connection to perform an HTML
form POST to send her message. The recipient views a web page to
read the message -- also using an SSL connection. To the outside
world, external to the Seagold server on Sealand, there is no evidence
that the email message ever existed.

Seagold is primarily designed to facilitate secure communications
between its members. Such messages are stored and transmitted only
internal to the server. For additional security in storage, or to
add a level of security on messages exchanged with non-Seagold email
correspondents, Seagold also supports the utilization of conventional
cryptography using either PGP (2.3.2 or 5.0) or GPG. Of course nothing
prevents a user from also pre-encrypting their message locally as they
see fit and then using Seagold to send it.

Is ours a perfect solution? No. We however believe it to be an
adequate solution, for most subscribers. One of the chief problems
with cryptography in general is that the security it affords is
directly a function of the understanding and savvy of the user. For
example, an ill-informed person might very well utilize a service
like Seagold or Hushmail to send a message to his friend at Hotmail,
and seriously believe that because he used a "secure service" to send
the mail, that the message is somehow secure. For these kind of
people, "secure email" services might actually be overtly dangerous
because of the false sense of security they create.

Seagold's approach has been to keep it simple, and to rely ONLY on
what we ourselves can control. We cannot control the security of the
user's computer. Thus we have no interest in running client side
applets in the user's browser, and then representing to the users that
their messages are therefore secure. How on earth would we know? The
security of our own server we can do our best to nurture and protect,
receiving also the assistance of Sealand/HavenCo in so doing (by
controlling physical access to the system). The security of the
customer's system we can influence in no way. This has made our own
design decisions quite clear.

We don't think anyone has a killer app or absolutely perfect solution
to the problem of email security. And due to the human elements
involved, it seems doubtful that an absolutely perfect solution will
ever be available. It's not about guarantees -- there are none -- it's
all about playing the odds. We hope that Seagold, and its sister site
Seamail (which is the same service only marketed without
the network marketing/MLM component; see http://sealand.pmmit.com)
can provide a useful service to casual encryption users in bettering
their odds, without requiring too extensive a knowledge base in
encryption generally".

http://seagold.net
http://sealand.seagold.net






---
You are currently subscribed to e-gold-list as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]

Use e-gold's Secure Randomized Keyboard (SRK) when accessing your e-gold account(s) 
via the web and shopping cart interfaces to help thwart keystroke loggers and common 
viruses.

Reply via email to