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 [EMAIL PROTECTED]
