Encrypted messages in unfriendly formats for external webmail services

[StuartLRM]

Description

When sending an encrypted message to an external mail service (i.e. not lavaboom) the message is headers and body are broken into two encrypted attachments. When decoded these messages include HTML and CSS tags and are not friendly to read. I would say they are not zero knowledge :-/

When sending to google mail only the encrypted header file is received. The body attachment does not appear.

Reproduction Steps

1. Create a non-lavaboom email account and a new public/private key pair
2. In Lavaboom add this new address as a new contact and add their public key
3. Send that contact an email containing a subject line and a message body
4. Observe that it is encrypted before it sends
5. Access the recipient email account and note that two attachments are present. One called "manifest.pgp" and one with the filename "application-pgp-encrypted-attachment". If the recipient is a gmail account note that you only receive the "manifest.pgp" attachment.
6. Open each file in the text editor of your choice. Observe each contains a PGP encrypted message
7. Decrypt each message with something like GPG Keychain ( https://gpgtools.org ) into which you've imported the recipient's private key
8. Observe that the "manifest.pgp" file contains the email headers inside a bunch of end-user unfriendly tags. e.g.

{"version":"1.0.0","headers":{"from":"stuart.mitchell@lavaboom.com","to":["arthur.t@gmx.us"],"subject":"This is my subject"},"parts": [{"id":"body","hash":"f93a40a1db4abec9df95d162fc0b182c4e95cb01f21d3908fc7e3ba49a070e35","content_type":"text/html"}]}

1. Observe that the "application-pgp-encrypted-attachment" when decrypted contains the message body inside a bunch of style tages e.g.

   <section class="email"><section class="body">This is the encrypted body message</section><footer class="signature"><br class=""><br class=""><p class="text-center"><a href="https://lavaboom.com" class=""><strong class="">Sent with Lavaboom - your secure email provider.</strong><br>Get your own address at lavaboom.com</a></p></footer></section>

2. As noted above if the recipient is a gmail account they won't get the actual body.

Here's a video screen-capture of the repro steps above: http://screencast.com/t/x4sfED3U7QUX

Suggested solution

1. The email subject line could not be encrypted and could be the email subject line (although I know there are good use cases for encrypting it)
2. The encrypted message should be stripped of styling for external accounts
3. The encrypted message itself should be presented as text in the external email - not as an attachment

[pasha-pivo]

Same thing happens to me. When sending an encrypted email (I used another my email account, not google) the recipient gets an encrypted file as an attachment that contains a strange text without the message body:

{"version":"1.0.0","headers":{"from":"user@lavaboom.com","to":["user@example.com"],"subject":"test test test"},"parts":[{"id":"body","hash":"8bb3a2cdb5c345a3f555246ba62e14e0bb2db6b331cf7e6c17ac104f81ab12d3","content_type":"text/html"}]}

The message itself is not encrypted. It contains a link to read the original message via web browser. When following the link I see this message in the web page: "Sorry, you've encountered a missing feature!". Enigmail which is a tool for working with PGP/GPG encrypting does not get that the message is encrypted (because it's not) When receiving an encrypted email from external email service (I used Thunderbird with Enigmail extension) I see encrypted message as a plain text, like this:

-----BEGIN PGP MESSAGE----- Charset: utf-8 Version: GnuPG v1

hQIMA0j2OXjZTKWvAQ//QRXzcSqfoTaES6DfYJPunCSKckJUNXuZrd4fHykKZuHi … /wbJefOXQFVLoYgS1nlQZ0vvidLTqRgCoav22kqOKwlDOE+511yPF+I= =TPs8 -----END PGP MESSAGE-----

When I'm saving the message on my computer as a plain text (via just copypasting) and then doing $ gpg savedmessage.txt it is decrypted correctly right away. I use Ubuntu; gpg tool is installed there by default. So it seems to me that lavaboom does not understand the messages encrypted with the keys generated by this service and does not encrypt messages so that other services could decrypt them though they use the same encrypting method. PS. Secret key has json extension and consists of the pair of the two gpg keys: public and private which can be both extracted from there easily and then used. That's what I did. So why so complicated?

[mdev88]

Same problem here when sending to Gmail. I receive only the manifest.pgp file and in the body of the message I get "This is an encrypted email, open it here if your email client doesn't support PGP manifests:" and then a link that sends me to a page that says "Sorry, you've encountered a missing feature! ".

I'm using GnuPG in my computer (Linux) and if I decode the manifest file I get a JSON file that contains the sender and destination emails and a hash of the message.

[andreis]

PGP manifests are what we use to encrypt email metadata (i.e. headers and mime info), but currently there are still some compatibility issues. There is a discussion on gnupg-devel about standardising this and making it backwards-compatible. Once that discussion settles we'll implement Memory Hole and hopefully this issue will be fixed.

[StuartLRM]

Hi Andreis - I had a quick look at the discussion - it looks like it's primarily concerned with headers - does it also address the issue raised above of style markup being encoded in the message? E.g. application-pgp-encrypted-attachment containing stuff like:

<section class="email"><section class="body">This is the encrypted body message</section><footer class="signature"><br class=""><br class="">

Apols if it does and I've missed it

[Nexus6]

Is there any news on this? The people who I've convinced to use PGP mail use either T-bird/Enigmail or Mailvelope, and both fail in the described way when processing received encrypted emails from Lavaboom. This makes it impossible to use the commercial Lavaboom service with them as there's no chance that I'm going to get them to migrate to using the service as their main email system.

[andreis]

@Nexus6 We're going through a back-end refactoring, and in the process we'll drop the current encoding scheme in favour of PGP/MIME - until Memory Hole is finalized. This means that for a (hopefully brief) window of time email headers will not be PGP encrypted.