SECURE EMAIL - JACMail2 Companion Program
Making email secure is easier said than done. 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.
The only way to truly protect a message is to encrypt it 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.
I wrote my own email client program because of dissatisfaction with what was commercially available. I even went so far as to implement TLS, but abandoned it after I realized how little protection it offered. Then I wrote an algorithm that embedded the key within the encrypted message. However, I again abandoned that effort because I could not guarantee that some hacker would not decompile my program and discover the algorithm. The worst part is that like most encryption systems, you never know when the system has become compromised.
So I set out to design a system that would work with existing mail systems and did not require the use of Public/Private keys.
1. Sender creates Random Key (eg. EE F2 26 2A BF C1 BC 7A). Key can be any size up to 512 bits.
2. Sender hashes the key, derives a new key from the hash, encrypts the message (not including message header), and encodes the message using Base64 (eg. XLVWGcE6aiWA5y94Bw==).
3. Sender then forwards the encrypted/encoded message as text (not flagged as encoded). It then hashes the encrypted/encoded message, derives a key from the hash, and uses it to encrypt the Random Key (eg. EE F2 26 2A BF C1 BC 7A is encrypted to 37 98 D9 A1 25 6D 1D 49). The encrypted Random Key, as well as the numeric value from the Message-ID (eg 41827.5099189815) are saved in a database.
4. Receiver retrieves the message, sees that it is encoded, and initiates decryption.
5. Receiver app displays a list of known encryption sources using the domain name from the Message-ID (eg <41827.5099189815@key.domain.com>). If the incoming Message-ID Domain Name is not included in the list, 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 encrypted key. The receiver then connects with the Message-ID Domain Name on a specified port, and sends the Message-ID to the Sender. The Message-ID server doesn't necessarily have to be the actual server that sent the message, but it must have access to the encrypted Random Key and the Message-ID.
7. The sender server looks up the Message-ID, and recovers the associated encrypted Random Key. It then sends the encrypted Random Key back to the receiver, and saves the IP address and date/time used to recover the key. This step provides protection against the contents of the message being modified. Subsequent requests from non-authorized addresses are ignored.
8. The receiver hashes the encrypted/encoded message, derives a key from the hash, and uses it to decrypt the Random Key. The receiver then decodes and decrypts the message, and saves the encrypted Random Key.
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, and appropriate measures should be taken. With most encryption systems, one never knows when or if the system has been compromised. For that reason, Asymmetric Encryption systems now require 2048 bit keys, and rather extreme security measures to protect the Private key.
J.A. Coutts
Note: The JACMailSvc program requires the Microsoft NT Service Control (NTSVC.ocx), which is readily available on the Net.
Making email secure is easier said than done. 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.
The only way to truly protect a message is to encrypt it 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.
I wrote my own email client program because of dissatisfaction with what was commercially available. I even went so far as to implement TLS, but abandoned it after I realized how little protection it offered. Then I wrote an algorithm that embedded the key within the encrypted message. However, I again abandoned that effort because I could not guarantee that some hacker would not decompile my program and discover the algorithm. The worst part is that like most encryption systems, you never know when the system has become compromised.
So I set out to design a system that would work with existing mail systems and did not require the use of Public/Private keys.
1. Sender creates Random Key (eg. EE F2 26 2A BF C1 BC 7A). Key can be any size up to 512 bits.
2. Sender hashes the key, derives a new key from the hash, encrypts the message (not including message header), and encodes the message using Base64 (eg. XLVWGcE6aiWA5y94Bw==).
3. Sender then forwards the encrypted/encoded message as text (not flagged as encoded). It then hashes the encrypted/encoded message, derives a key from the hash, and uses it to encrypt the Random Key (eg. EE F2 26 2A BF C1 BC 7A is encrypted to 37 98 D9 A1 25 6D 1D 49). The encrypted Random Key, as well as the numeric value from the Message-ID (eg 41827.5099189815) are saved in a database.
4. Receiver retrieves the message, sees that it is encoded, and initiates decryption.
5. Receiver app displays a list of known encryption sources using the domain name from the Message-ID (eg <41827.5099189815@key.domain.com>). If the incoming Message-ID Domain Name is not included in the list, 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 encrypted key. The receiver then connects with the Message-ID Domain Name on a specified port, and sends the Message-ID to the Sender. The Message-ID server doesn't necessarily have to be the actual server that sent the message, but it must have access to the encrypted Random Key and the Message-ID.
7. The sender server looks up the Message-ID, and recovers the associated encrypted Random Key. It then sends the encrypted Random Key back to the receiver, and saves the IP address and date/time used to recover the key. This step provides protection against the contents of the message being modified. Subsequent requests from non-authorized addresses are ignored.
8. The receiver hashes the encrypted/encoded message, derives a key from the hash, and uses it to decrypt the Random Key. The receiver then decodes and decrypts the message, and saves the encrypted Random Key.
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, and appropriate measures should be taken. With most encryption systems, one never knows when or if the system has been compromised. For that reason, Asymmetric Encryption systems now require 2048 bit keys, and rather extreme security measures to protect the Private key.
J.A. Coutts
Note: The JACMailSvc program requires the Microsoft NT Service Control (NTSVC.ocx), which is readily available on the Net.