argonne-national-laboratory / megthunderbird Goto Github PK

We need to add the option to fully trust a client and transmit the private key from the phone to the client for local decryption.

This will also serve as a private key backup in the case of phone theft or loss.

When multiple messages are sent in a conversation between two people, the new reply is decrypted, however, the original message remains encrypted in the response.

Got it!!!! On 7/1/16 12:20 PM, miket wrote: iQEcBAABAgAGBQJXdqZ3AAoJECh4IIBb8PqS2X0H/iJX6QdZhAiShkBTVDHJUki28KTsteDqQmhiOFc3AeZ6sYDVOsVAiVo5M+c14j24/J5U7NmiIcjRaxNGCa9oSOBgu2fiv2Z9bweyl81HoqIqG2PeH20n0N0SQqvZHPFyGLxIWxSxtAqfAJbzbQlBkg4tH2uMwEIJpqggxLhUVRs6U2Vf0YHssoAD/vewNx3qq+/Zwavi7gw4ge1iYLtoPywscB2XuUeE+EjCf61nVt9bSFbeOwTiIXtizuXbcECJiSbaTdcRe4qyfzYFMzr26MbP7AgGPKVECZKR/75ntIX/NhYitdu1XvJqcgpSpVa29tRhAlJ+0/s46ne3xeQllf0mJl4mJioqKiYmXiYmSogmogSw72uq5HaLKs0aaM/87hkFnbDLxsEru0r+kJCFAQwDg8kmrN/4ihUBB/9LvtDKp3ilbUgVPHSD2LU92LYa2zYzD5mkEgjYsh55tkePz0BQHRpRks5+fO7ltzQksdT5dgENQSuPTX+l2DvVh87xBSOyNJvw2PeuFK2Bwc9D06yU+7xqxPWXANcU7ltrY7x6TNZQAG+kBZzH+ri9yFQkVjJWOnPTEFrNPAFJBKVn+goxRhrlw0VWoPGpe7oWAG1pCgzJc+1TbVu4HJoq7yByqerW27B9UWiDBaFnqIl+ZcLv5S2Hqdg+paTCMXaYN3bbudmDKdU5F14K9+w463WbFpX8D5Wu//A3V7zSJj5A8/Lq62DVfFbvdUDhDnukpdheALj0e+tiYfZ8VCj10mMByapiYFLf5I+FYTDI7LIVycCvL96x5/KH1zKoS2duDvtwTzBaJ9R3K8FpfR9RE/4+XoIEk96407E/yWR2/+qEeAC699QLBYejL3vT61xjomwhPrnUfonjahmk3i1F/Hludbo=

When sending a message, trust levels should be visible for each recipient. Levels of trust should be signaled by subtle color coding. Green should be used if the key has been NFC signed. Yellow should be used if the key can be verified through Web of Trust. Red should be used if a key has no signatures, cannot be found or has been revoked without being replaced.

The QR code shouldn't have a button. Instead, this process should be automated. After the user takes a picture of the QR code with his or her phone, the symmetric key data should be saved.

After installing the Thunderbird add-on, the user should be presented with a post-installation screen. This screen should have a header stating that MEG is now installed. This screen should have detailed instructions on how to use MEG, complete with screenshots. It should also have a checkbox that says, "Don't show this again" to allow the user to suppress it.

The level of trust for each sender should be visible when viewing a received message. See #7 and the, "Sending a Message Flow Chart" pdf for more information.

In the work plan it's noted that this screen should have a description/explanation. I imagine this would be a blurb talking about "blessing" and why there's a QR code.

On Thunderbird 45.2.0 (Linux), after installing via the downloaded .xpi file, MEG is not operational. The addon shows as being installed, however, none of the MEG functionality is accessible. The Thunderbird error console shows the following:

Warning: Failed to load overlay from chrome://megthunderbird/content/chrome/receive.xul.
Source File: chrome://messenger/content/messenger.xul

No chrome package registered for chrome://megthunderbird/chrome/content/send.xul
No chrome package registered for chrome://megthunderbird/chrome/content/send.xul

Warning: Failed to load overlay from chrome://megthunderbird/chrome/content/send.xul.
Source File: chrome://messenger/content/messengercompose/messengercompose.xul

No chrome package registered for chrome://megthunderbird/chrome/content/qrinsert.xul
No chrome package registered for chrome://megthunderbird/chrome/content/qrinsert.xul

Warning: Failed to load overlay from chrome://megthunderbird/chrome/content/qrinsert.xul.
Source File: chrome://messenger/content/messengercompose/messengercompose.xul

It should be possible to sign the keys of incoming users via SMS or Facebook.

A recipient is not fully trusted if his key has no signatures, cannot be found, or has been revoked without being replaced. In some of these scenarios an encrypted email might not be possible. In these cases the sender should be prompted for further action. The following actions should be available to the user:

1. Send unencrypted
2. Send encrypted anyway (but only if key was found that had no signatures)
3. Request verification (if key has no signatures)
4. Send invitation (if key could not be found or has been revoked)

Verification, when needed, should be possible via Facebook or SMS.

Public PGP keys should be cached in a keyring. The client should check the cached keyring for the key before making a DNS request to the server.

Decryption doesn't work with Thunderbird Conversations... pretty low priority, but wanted to have it tracked.