Email Encryption

Discussion in 'encryption problems' started by John Chapman, Jan 9, 2019.

  1. John Chapman

    John Chapman Registered Member

    Joined:
    Aug 16, 2018
    Posts:
    1
    Location:
    Austin, Texas
    Most message are sent and received without either party being aware of encryption. It is built in to default email systems on Windows PCs, Macs, and our smart phones, or is it?

    Normal asymmetric encryption only using the recipient’s public key does not provide nonrepudiation evidence that the implied sender sent the message. On the other hand, if the message is encrypted using the sender’s private key (effectively a digital signature) then anyone with the sender’s public key can read a message therefore confidentiality is lost. Only using a 2-step approach with asymmetric encryption can both confidentiality of the message and nonrepudiation of sender be confirmed:
    • Sender 1st encrypts the message with the recipient’s public key,
    • Sender 2nd encrypts the message using the senders private key and sends email message to recipient
    • Recipient 1st decrypts the message using the sender’s public key
    • Recipient 2nd decrypt the message using the recipient’s private key

    What level of automated encryption/decryption is provided on Windows PCs, Macs, and smart phones?

    How are public keys securely exchanges in the automated process?

    Do any of the automated handle something like the 2-step asymmetric encryption process detailed above?
     
  2. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    8,337
    Well, SSL/TLS (or STARTTLS) transport security is common now, between users and the mail servers that host their accounts. But SMTP connections among mail servers are still often unencrypted. Especially for smaller operations. For all its faults, Google encrypts everything that it can. Also, messages cached on intermediary mail servers are also often unencrypted.

    So the only way to have reliable end-to-end encryption is for senders and recipients to encrypt and decrypt locally. The main options are GnuPG and S/MIME, with S/MIME being more common for Windows users.

    But still, even with reliable end-to-end encryption, metadata (time, to, from, subject, message id, etc) do not get encrypted. Some of that metadata can't be encrypted, because it's needed for message routing. You can work around that by using webmail. So everything between you and the server is encrypted. And they handle the encryption after setting up message routing. But then you need to trust the provider with your private key.
     
  3. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    583
    STARTTLS is good but unfortunately it's opportunistic and can be easily disabled by adversary. All active attacker have to do is just strip the STARTTLS out of the handshake between client and traditional server and then can just log the unencrypted traffic. (I think Tunisia was one country that did/does it and Thailand another one)

    I find it sad that the folks at IETF did not push the mandatory SSL-encryption method (it was first at port 465 but then given to some other service) into standard. Of course, I can do whatever I want with my own e-mail server and clients but still.....

    Mandatory SSL-encryption (you either encrypt or fail, no third option aka sending unencrypted) with certs checking (maybe Dane) and the e-mail situation would be much more better.

    EDIT: Also about the PGP, it's horribly ancient and not very robust by todays standards and needs major upgrade. At least by one cryptography expert
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.