Results 1 to 2 of 2

Thread: VB6-JACMail Crypto Service

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    VB6-JACMail Crypto Service

    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.

    Updated (08/23/2014): See next post for details
    Attached Files Attached Files
    Last edited by couttsj; Aug 23rd, 2014 at 09:09 AM.

  2. #2

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,470

    Re: VB6-JACMail Crypto Service

    JACMail2 sent the Message-ID in clear text to the Key Server. If a man-in-the-middle was able to obtain the original encrypted message, he/she would be in possession of the ID and could monitor network traffic for that ID. The hacker could then intercept the returning packet with the encrypted key. He/she would then have all the necessary ingredients to decrypt the original message, and we would be none the wiser.

    Consequently, the JACMail2 and JACMailSvc programs have been changed to provide protection against this type of attack. The following points in the orginal post have been changed to reflect that, as well as the downloads themselves:

    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 Exchange Public Key with the Message-ID embedded in it. 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 encrypts the Random Key with the Exchange Public Key, and sends it back to the receiver. It then 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 uses the Exchange Private Key to decrypt the Random Key. He/she then 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.

    This has required the addition of two new routines to the clsCrypt Class; ExportSessionKey and ImportSessionKey.

    The reason for using the Exchange Key Pair is that it is automatically generated by the Operating System and requires no user intervention. This still aligns with the original target of not having to manage keys.

    A DNS cache can be poisoned to point a user to different site than the intended one. For the truly paranoid security buff, the Key Server location can be programmed into the HOSTS file on the Client machine to protect against this. It also has the advantage of being much faster and allowing a server on a dynamically assigned IP address to be more easily adjusted for.

    J.A. Coutts

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width