BETA solution, Re: Failure of PKI in messaging

[Ed Gerck]

James A. Donald wrote:
> Ed Gerck wrote:
>> I am using this insight in a secure email solution that provides
>> just that -- a reference point that the user trusts, both sending
>> and receiving email. Without such reference point, the user can
>> easily fall prey to con games. Trust begins as "self-trust". Anyone
>> interested in trying it out, please send me a personal email with
>> application info.
> 
> Want to try it out.  Not clear what you mean by application info.

The application info is just so I can verify your requirements.
The solution is in BETA and does not use Java, Flash, stored cookies,
or ActiveX. Works in Linux, Mac, and Win. There's also a javascript-
free version (earlier BETA).

The solution is available free (for personal use)
at https://zsentry.com/zmail/emailsecurity.html
Summary is available at http://zsentry.com and how it works at
https://zsentry.com/privacy_security_compliance_zmail.htm

The question is: Why should I trust it?

Zmail actually reduces the amount of trust by not storing your usercode,
password, or keys anywhere. This makes sense for zmail, and is an incentive
to actually do it, to reduce risk -- anyone breaking into any zmail server,
even physically, will not find any key or credential material for any user
and, hence, cannot decrypt any user area (the user area keeps the address book
and contact keys, all encrypted using the user keys that are not there), or
user messages collected from ISPs.

This is more than X.509 or PGP can do, as the private-key must be exposed
somewhere.

Next, let's see what zmail does. It creates a point-to-point encrypted
channel, with authentication, delivery and control mechanisms that you define.
It's a secure routing/delivery system, working as an add-on interface (so it
does not change how you use email).

The message itself could be encrypted by you and just delivered by zmail
-- so that you have the secure routing/delivery from zmail but do not have
to trust zmail with your plaintext.

This will actually be available in v3.x, with an option for client-based
super-encryption. If you are concerned about zmail peeking into the raw
message, which zmail does not do, you can simply agree with your message
partner on an out-of-band passphrase and use it in your client (without
zmail access) to encrypt. Your recipient can do the same to decrypt. What
you get from zmail is the secure routing and distribution -- for example,
you can require the recipient to login, allow the recipient to prevent
phishing, and expire the message in 7 days. You can also request a return
receipt telling you when, where, how, and by whom the message was decrypted.

While version 3x is not there, or even afterwards, you can do the same with
any publicly available file encryption and just attach the encrypted file
or paste its ASCII into the message panel. You don't have to worry about
user registration, anti-phishing, authentication, delivery control or use,
as all this (and more) is handled by zmail.

Thank you for your interest and I look forward to your feedback.

Best,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com