JACMail Version 2.5 is very similar to Version 1 on the surface. Under the hood however, there have been substantial changes. JACMail is an Email Client Program designed to allow fast and efficient recovery of email from a POP3 server, and the sending of email through an SMTP server. It is primarily oriented towards text based messaging with attachments, and does not directly support highly formatted HTML based email or embedded objects. It receives and stores both text/plain and text/html messages, and Web based emails (HTML) can be sent to your default browser for viewing. It also supports Plain Authentication based POP3 and multiple mailboxes. The mailboxes are stored in an Access database utilising ODBC.
The code uses IP Version independent system calls, so it will only work on Windows systems that actively support both IPv4 and IPv6. That more or less restricts it to Windows Vista or later. It has been tested on Windows Vista, Win 7, Win 8.1, and Win 10, and utilises the following standard components and references:
RICHED32.DLL
RICHTX32.OCX
COMDLG32.OCX
MSSTDFMT.DLL
MSBIND.DLL
MSADODC.OCX
MSDATGRD.OCX
which the user must have available in order to compile the program. It also uses a VB6 compiled Library file called jCrypt.dll, which is available here:
http://www.yellowhead.com/documents/jCrypt.dll
This DLL handles all the Cryptography functions, and should be copied to the %windir%\system32\ directory (%windir%\syswow64\ on 64 bit systems).
JACMAIL Version 2.0/2.5 both support message encrytion. Version 2.0 utilized RC4 for bulk encryption, which is no longer considered secure. It also used RSA to transfer the key from the server component to the client component. Version 2.5 now uses ECC (Elliptical Curve Cryptography) to transfer the encryption key. The advantage of using ECC is that keys do not need to be stored, as a different key is used every time. Even if a hacker manages to break the ECC key for one message, it is useless for the next message. Version 2.5 uses a proprietary method of encryption, and for the moment will remain so. Although any JACMail2 Client can receive and decrypt messages sent by JACMail2, the sending of encrypted messages requires a server component.
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 encrypted 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 with encrypted messages.
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 records 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 encryption 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.
Critics will say that the message could be intercepted, and the Msg-ID sent to the server to recover the Encryption Key. That is true, but one of the drawbacks of most encryption systems is that it is difficult to determine when it has been compromised. JACMail 2.5 overcomes that limitation.
Note: The service component requires the Microsoft NT Service Control (NTSVC.ocx).
The code uses IP Version independent system calls, so it will only work on Windows systems that actively support both IPv4 and IPv6. That more or less restricts it to Windows Vista or later. It has been tested on Windows Vista, Win 7, Win 8.1, and Win 10, and utilises the following standard components and references:
RICHED32.DLL
RICHTX32.OCX
COMDLG32.OCX
MSSTDFMT.DLL
MSBIND.DLL
MSADODC.OCX
MSDATGRD.OCX
which the user must have available in order to compile the program. It also uses a VB6 compiled Library file called jCrypt.dll, which is available here:
http://www.yellowhead.com/documents/jCrypt.dll
This DLL handles all the Cryptography functions, and should be copied to the %windir%\system32\ directory (%windir%\syswow64\ on 64 bit systems).
JACMAIL Version 2.0/2.5 both support message encrytion. Version 2.0 utilized RC4 for bulk encryption, which is no longer considered secure. It also used RSA to transfer the key from the server component to the client component. Version 2.5 now uses ECC (Elliptical Curve Cryptography) to transfer the encryption key. The advantage of using ECC is that keys do not need to be stored, as a different key is used every time. Even if a hacker manages to break the ECC key for one message, it is useless for the next message. Version 2.5 uses a proprietary method of encryption, and for the moment will remain so. Although any JACMail2 Client can receive and decrypt messages sent by JACMail2, the sending of encrypted messages requires a server component.
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 encrypted 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 with encrypted messages.
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 records 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 encryption 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.
Critics will say that the message could be intercepted, and the Msg-ID sent to the server to recover the Encryption Key. That is true, but one of the drawbacks of most encryption systems is that it is difficult to determine when it has been compromised. JACMail 2.5 overcomes that limitation.
Note: The service component requires the Microsoft NT Service Control (NTSVC.ocx).