JACMail Version 2.5 Back to Home Page

Version 2.5 of JACMail on the surface looks pretty much like Version 1, and operates the same. The differences are all under the hood.
- Cryptographic functions are now provided by a library file (jCrypt.dll).

JACMail2 is written in VB6, and is being made available in ZIP format. Installation is usually straight forward, using "setup.exe" to install files extracted from "JACMail2.cab" as laid out in "setup.lst".

Version 2 used the RC4 protocol for bulk encryption. That protocol is no longer considered secure, and has been replaced by a proprietary method of encryption. Version 2 also used the built in RSA key to transfer the encryption key. Version 2.5 uses ECC (Elliptical Curve Cryptography), and thus uses a different key every time to tranfer the encryption key. Hacking the transfer key for one message is useless for the next message.

Only the message itself is encrypted, which does not include the Body Header information. Since encryption uses full byte characters (8 bit), and email only supports ASCII (7 bit), the encrypted data must also be Base64 encoded. Because the Header information remains unencrypted, all the normal email protocols are maintained. A stand alone JACMail Client can receive and decrypt encrypted messages, but to send encrypted messages, JACMail requires a server component. Every time the Send Message function is activated, it verifies that the server component is available. If you try to send an encrypted message without the server component, you will get a warning message. Each message uses it's own unique Key, and attachments are not encrypted.

JACMail 2.5 now allows you to encrypt regular messages for storage in the database. A secondary password is required to perform any encryption function. It only has to be entered once per session. When you encrypt a regular message and close the window, the program will ask you if you want to save the message in the encrypted form. If you respond with a "Yes", and you have already entered the secondary password in a previous operation, the save is made without any further input. Otherwise, you will be prompted to enter the secondary password, and asked again to save it. Please remember that only the information displayed in the scrollable window will be encrypted. If the message was received with both plain text and HTML text, and you want to encrypt both formats, you must bring the HTML text forward by viewing the header, and then viewing the message again. Once saved as encrypted, you cannot reverse the operation.

Encrypted Message as Received.

Decrypted Message.

This type of encryption is sometimes referred to as "End-To-End Encryption", as the only true way to ensure message security is to encrypt the message at source, and decrypt it at the final destination. PGP does this and has been around for ages, but has not gained very wide acceptance. The difficulty is that it requires the use of Public/Private key pairs, and most non-technical users have difficulty managing keys. Some people are under the illusion that TLS (Transport Layer Security) provides protection, but nothing could be further from the truth. As the name suggests, TLS only provides protection during a single transport leg. It does not protect the message at the source or the destination, nor any of the MTA's in between. In one respect TLS is overkill because it encrypts everything, when in reality the only component that needs to be encrypted is the message itself. The body header does not need to be encrypted.

1. Sender creates Key. For example:
E2 18 F8 A9 78 C7 B4 57 5A 59 42 AE 86 D6 55 59
B7 D4 A4 10 F8 AE 79 B9 52 F0 2B 2E C1 56 43 56
All keys are 256 bit.

2. Sender encrypts the message (not including message header), and encodes the message using Base64 (eg. rIhJjXo+Shn15tj7RxHPwZiEpcGNyg==).

3. Sender then forwards the encrypted/encoded message as text (not flagged as encoded), and sends the key and the Message-ID to the server to be stored in a database.

4. Receiver retrieves the message, sees that it is encoded, and initiates decryption.

5. If the sender Domain recovered from the Message-ID (eg <41827.5099189815@key.domain.com>) is contained within the list of known encryption sources that the program keeps track of, then this step is skipped. Otherwise the receiver app displays the list of known encryption sources along with the current one, and the receiver is prompted to add it to the list with a warning. This step provides a degree of protection against phishing.

6. At this point, both the sender and the receiver possess the encrypted message and the sender possesses the encryption key. The receiver then connects with the Domain Name from the Message-ID on a specified port, and sends the Message-ID and it's Elliptical Curve Public Key to the server.

7. The sender server looks up the Message-ID, and recovers the associated encryption Key. It then creates an Agreed Secret using it's own private ECC Key and the public ECC Key from the receiver. The encryption key is encrypted with the Agreed Secret and sent back to the receiver along with it's own public ECC Key. It then saves the IP address and date/time used to recover the key. This step provides a degree of protection against the contents of the message being modified. Subsequent requests from non-authorized addresses are ignored.

8. The receiver creates the Agreed Secret using it's own private ECC Key and the public ECC Key from the server. This Agreed Secret is used to decrypt the encrypted key from the server, which is then used to decrypt the Base64 decoded message. Finally, the key is saved in the receiver's database.

9. Subsequent requests to decrypt the message use the saved key.

10. The sender now knows when the message was read. Subsequent requests for the key would be highly suspicious and are blocked, with manual intervention required to unblock. If it is later discovered that an unauthorized request was made for the key from an unknown IP address, the contents of the message have probably been compromised.

JACMail is written using IP version independent system calls. Therefore, it will not work on Windows Systems that do not actively support dual stack. This more or less restricts it to Windows Vista or better. Other than the new cryptographic functions, all the support offered in the Version 1 is still applicable to Version 2.5. Version 2.5 uses a slightly different database, so a new database must be used.

JACMail Service!

Note: JACMail 2.5 has been tested on Win Vista, Win 7, Win 8.1, & Win 10.

Note: If you are upgrading from Version 2.0, you will have difficulty with the secondary password. Email me for instructions.

Back to Top

| Home Page