- Introduction
- Configuration
- Keys
-
Email Clients
- Basic Email Client Configuration
- Outlook XP/2002
- Modifying Outlook XP/2002
- Outlook 98/2000/Express
- Modifying Outlook 98/2000/Express
- The BAT
- Modifying The BAT
- Pegasus
- Modifying Pegasus
- Eudora
- Modifying Eudora
- Calypso
- Modifying Calypso
- IncrediMail
- Modifying IncrediMail
- Netscape Mail
- Modifying Netscape Mail
- Technical
-
FAQ
- What email clients work with SecExMail ?
- Does SecExMail work with IMAP?
- How secure are SecexMail keys ?
- Is SecExMail legal in my country ?
- Does SecExMail support signatures ?
- Does SecExMail work with PGP ?
- Is the source code available for SecExMail ?
- Why can I not mix clear text and cipher recipients ?
- About
| Previous Top Next |
Email Encryption for Windows
The SecExMail Cipher
The SecExMail cipher is a composite cipher specifically designed to operate on real-time email streams. It uses cryptographic primitives which are available to the general public and have been subject to extensive peer review. The SecExMail cipher incorporates RSA public key encryption. Message encryption is performed via the Twofish block cipher and the ISAAC stream cipher. The SecExMail cipher is warranted to be free from spy-ware, key escrow or key recovery features of any kind. The email encryption process is described in detail below. See diagram. |
|
SecExMail Composite Cipher
Stage 1
Email data is received in variable length data blocks. SecExMail parses SMTP header info, mail and data bodies.
Stage 2
Because email messages frequently contain known plain text, such as salutation and or tag lines, which gives rise to known plain text attacks on the encrypted message and in order to minimize overall message expansion, the plain text is first compressed using the ZLIB compression algorithm. The net effect of deflating large amounts of data, containing both tidbits of known plain text such as greeting or tag lines as well as unknown message text into a compressed data stream is that any known plain text is effectively obscured.
Stage 3
The ZLIB stream has a fixed header format which in itself might be exploited as known plain text by a savvy cryptanalyst. For this reason, the first 64 bits of the steam are enciphered by way of a One Time Pad, using standard XOR masking. This approach acknowledges that email messages will contain portions of known plain text and proactively manages this problem.
Stage 4
At this point the compressed data is encoded using the 64 bit ISAAC stream cipher creating the layer one cipher text.
Stage 5
The next step in the encryption process is to encrypt the layer one cipher text using the 256 bit Twofish block cipher. Twofish is used in chained block mode, but instead of XOR'ing the previous block's cipher text into the plain text of the current block, the output from the ISAAC layer is "chained in". This chaining process is illustrated below.
ISAAC Twofish Block Chaining
Stage 6
The final step is to assemble the output in base64 transfer encoded format for transmission via mail transfer agents (MTA).