1. The Hush user (or the Cyber-Rights.Net user) downloads the Hush applet via the World Wide Web, having entered his or her address name.

2. The Hush applet, running on the client machine, requests the user's passphrase.

3. The passphrase is entered. Then, it is securely hashed. Part of this hash is sent to the HushMail server for user validation.

4. Only if the partial hash is valid, will the HushMail server send the client Hush applet the Hush user's public key and encrypted private key.

5. The Hush applet symmetrically decrypts the encrypted private key into its plaintext form.

6. The Hush user enters the system and can view email, create address aliases, compose email, and utilize other features of the HushMail service (Cyber-Rights.Net service).

7. When the Hush and/or Cyber-Rights.Net user composes and sends a message, the Hush applet contacts the HushMail server and downloads the recipient's public key.

8. If the recipient is in the sending Hush user's address book, it compares the public key values against an electronic fingerprint for extra security.

9. The body of the email message being sent is symmetrically encrypted with a randomly generated session key.

10. Using the recipient's public key, the random session key is asymmetrically encrypted and added to the message that is sent to the recipient.

11. The entire message is sent to the HushMail server, which sends the message out to the Internet using SMTP.

12. When the recipient reads the message, the recipient's private key will decrypt the session key, which will yield access to the plaintext message itself.

Some finer clarifications:

1a. Refer to 1a under the "Address Creation Process" section of this document. Please note a different applet is used in this example.

2a. The passphrase is never transmitted from the client machine.

3a. The HushMail server only releases encrypted private keys to strongly validated users. This limits possible risk of high-speed, brute force attacks trying to recover either the Hush user's passphrase or plaintext private keys. If the HushMail server detects multiple tries in a short period, such as someone trying to guess a user passphrase, it will notify a system administrator and/or temporarily stop accepting requests from that address name and/or IP address.

4a. This operation is the same as 5a, except in the reverse.

5a. All public keys of HushMail users are available. They are retrieved during the encryption process, prior to transmission of the encrypted message

6a. If a sending Hush user distrusts the HushMail server itself, the sender may put the recipient address in his or her address book. By doing so, the sender can view the hash (or "fingerprint") of the recipient's public key before sending the message. Both sender and recipient may exchange fingerprint information at any time, any way they wish.

7a. The randomly generated Blowfish algorithm is 128-bits long. It is created by differences in keystroke timing from the Hush user after being securely hashed with SHA multiple times.

8a. The HushMail message format is a hybrid symmetric encryption/public system, created for speed and efficiency. Once messages have been read, they are stored via symmetric encryption. The session key is stored in the email header. Messages sent to oneself are symmetrically encrypted only.