Improving the user experience of PGP is a key factor for wider adoption of email encryption. One of the major obstacles is the key exchange. If a manual key exchange is required before starting a secure communication with PGP, the barrier is often too high. This is shown by studies like "Why Johnny still can't encrypt".
The success of the Signal protocol, which is or will be used by almost all big players in the messenger market, reminds us that a deployment of end-to-end encryption is possible for billions of users.
But not with a manual key management, or as Matthew Green has put it in his post "What’s the matter with PGP?":
Manual key management is a mug's game. Transparent (or at least translucent) key management is the hallmark of every successful end-to-end secure encryption system. Now often this does involve some tradeoffs -- e.g., the need to trust a central authority to distribute keys -- but even this level of security would be lightyears better than the current situation with webmail.
In this post we want to present our approach to transparent key management and further user experience improvements.
Mailvelope v1.5.0 focuses on improving the user experience in several key areas.
Google Mail and Google App users no longer need to enter recipient email addresses twice.
Mailvelope will read recipient addresses from the webmail UI when opening the editor to write encrypted messages. If the user adds or removes additional recipients, those will be transferred back to the webmail UI as well. Support for other webmail providers is planned.
If both the recipient and the sender are using the current release of Mailvelope, they will no longer need to exchange public keys manually.
When writing a new message, public keys will be fetched automatically while typing in recipient email addresses. This will work for any Mailvelope user that has verified their email address using the current version.
While we would like to improve the usability for as many users as we can, we also understand that some users might not want auto-lookup and key upload to be enabled.
This new and improved user experience is fueled by a new piece of technology that we are excited to share today. We’ve built a simply key server that works similarly to the Signal backend. It verifies email addresses using an encrypted verification email. This not only verifies email address ownership but also provides cryptographic proof of private key ownership.
You can learn more about our key server at keys.mailvelope.com. The code is licensed under the AGPL v3.0 and is developed completely in the open on GitHub. If you’re a developer you can also learn more about the API in the documentation.
We want to make it as easy as possible to write encrypted email between users of different platforms and form factors. That’s why we’re excited to announce that we are working together with GPGTools for macOS to make it completely painless to write encrypted email between our users. GPGTools is in the process of integrating the Mailvelope Key Server and will also be providing an automatic key lookup user experience.
In addition, we are gathering feedback for the key server from the PGP community at the OpenPGP Summit in July.
The recently published version 1.4 of Mailvelope comes with new features for encrypting files. A search function allows now to import keys from public key servers.
With the file encryption feature of Mailvelope you can encrypt files on your hard drive according to the PGP standard. In the same way as email encryption, the files will be encrypted with the public key of the receiver.
More details can be found in the Documentation File Encryption.
Email providers that directly integrate Mailvelope into their email application will support encrypted email attachments automatically. For email providers like Gmail™, Yahoo™ or Outlook.com™ there are restrictions in the Mailvelope editor and encrypted attachments are not directly supported. With the availability of file encryption Mailvelope offers an alternative: encrypting email attachments can now be done manually.
A search field in the Mailvelope key management area simplifies the search on public key servers. Keys can directly be imported from the search results of the key server.
More information on the search functionality in the Documentation Key Handling.
The two major German email providers GMX and WEB.DE today announced the availability of PGP encryption based on Mailvelope. A great deal of development efforts was put into the Mailvelope Open Source Project over the past 12 months resulting from the collaboration between 1und1 and Mailvelope GmbH, and as of today, the 30 million clients subscribing with GMX and WEB.de can start using the integrated End-to-End encryption for the first time.
The groundbreaking convergence of browser extension and web application has reached an unparalleled degree of user friendliness without compromising security. That way, Mailvelope contributes significantly in making secure communication a viable and attractive solution for the everyday user.
Using a Mailvelope API (Application Programming Interface) that is basically utilizable for other providers, secure containers inside the GMX and WEB.DE email clients are generated, within which PGP messages (and file attachments) can be read and generated. The user is able to identify the Mailvelope containers through an individual security backdrop at any given moment, and at no time will confidential data reach the Mail provider without encryption.
This is where Mailvelope stands out from server-side PGP-solutions such as OX Guard / mailbox.org. These may contribute to a further prevalence of PGP, but they cannot be regarded as End-to-End Encryption: the private key is on the server; the messages are encrypted and decrypted directly at the provider, which is why the User always needs to rely on the server and the provider. The contention that this is a protection against unsafe end devices falls short of the issue it is trying to address because when using this approach, the message and the files arrive at the end device without encryption in each instance, which is why the security of the data always depends on the quality of the end device. The server-side approach makes for centralized structures that constitute potentially worthwhile targets for attacks.
Mailvelope addresses the issue of assigning the private key to several end devices through a generated 26-digit retrieval code. This code is generated on initial setup in an optional step and will then be entered by the User on all other devices. Following, the private key can be synchronized from the cloud. The package containing the private key has a strong encryption (AES-256) and can only be opened using the 26-digit randomized password. This encryption has a very high level of security and, according to current knowledge, will not be vulnerable to cracking beyond 2030. Experts in the field agree that the weak spots of any system concerning secure communication are not found in current algorithms such as AES, or, like Snowden has put it, “Encryption works“.
After initial setup, mobile devices such as the iOS and Android apps by GMX and WEB.DE can be used for PGP encryption. In this case, also the contacts (public keys) of the User are synchronized. Once a contact has been added (with optional fingerprint verification) to Mailvelope, it will then automatically be synchronized to other devices. To accomplish that, Mailvelope taps provider-neutral formats.
Today, the two German telecom providers Deutsche Telekom and United Internet (1und1, Web.de, GMX.de) announced to provide end-to-end encryption for users of De-Mail. The Mailvelope browser extension will be integrated into the De-Mail webmail client and be used for all PGP related encryption services. In the last months we have worked together with 1und1 and Deutsche Telekom on this integration to improve the usability of PGP in a webmail environment and at the same time enforcing strong boundaries between browser extension and De-Mail web server.
The Mailvelope browser extension is available for Google Chrome since 2012. In its current mode of operation PGP capabilities are added to the frontend of supported webmail providers. The advantage of this approach is that all encryption relevant services and the key storage are encapsulated in a locally installed browser extension which is isolated from the webmail client.
To integrate with the De-Mail system Mailvelope developed a client API that further improves usability and adds features like encrypted attachments. Mailvelope's secured user interface components can be seamlessly embedded into web applications. The API is open, documented and available for review in our GitHub repository.
We are excited to partner with the DE-Mail alliance and bring end-to-end encryption to a wider audience.
Mailvelope v0.8.0 is now based on a new version of OpenPGP.js after a major redesign of the library. With its modular design, a new high level API, improved compatibility to the OpenPGP standard and various other improvements we now have a solid foundation for the future development of Mailvelope.
In February 2014 Cure53 conducted an audit of the complete code base of OpenPGP.js. The penetration test yielded an overall of 26 issues. All critical, high and medium issues have been fixed. The complete report and status of the bug fixing can be found in the OpenPGP.js wiki. We continue to disclose all security audits to provide best possible transparency in our development process. See here also statement from OTF on "Bringing Openness to Security".
Spoofing of cleartext signed messages: Mailvelope does not support verification of cleartext signed messages as of now and therefore was never vulnerable to this attack.
EME-PKCS1-v1_5 padding with weak random numbers: messages sent with Mailvelope prior to v0.8.0 are vulnerable to the "known padding" (aka "stereotyped message") case, an attack to recover the encrypted message is possible due to Coppersmith. However, the attack is only feasible if the used RSA key meets a certain "at-risk" condition:
An RSA encryption key is at risk if its modulus size is >= 256 times its public exponent. This condition is not met by most PGP keys. Probably fewer than 1/1000 PGP keys are "at-risk".Trevor Perrin, OTF Red Team
The complete analysis on the EME-PKCS1-v1_5 padding bug is available in the Mailvelope wiki.
Keys generated with Mailvelope have a higher exponent and are therefore "safe". Also the found numbers suggest that RSA keys generated with most modern software after the year 2000 are not in a risk condition.
The risk is further mitigated by the fact that, for Mailvelope on Google Chrome, a recovery of the padding is only possible for messages created within the same browser session. That means, given a target message from a "at-risk" key, an attacker requires the padding from a second regularly decrypted message created in the same browser session as the target message.
The Mailvelope editor now allows the signing of messages.
Make now a backup of your keyring with the Export all keys feature.
Thanks go to all contributors of release v0.8.0, especially to the Open Technology Fund (RFA) for sponsoring the project. The Cure53 team for the thorough review and the improvements brought to OpenPGP.js. Also thanks to Trevor Perrin for further security analysis and assistance.
More than seven months have passed since our last major release, and today we are excited to announce the availability of Mailvelope v0.7.0.
The performance of the key grid has been optimized in order to reduce the initial loading time and allow the handling of a large number of keys. The key import function has undergone a complete rewrite and now provides a better logging mechanism for warnings and errors during the import process.
One way to exchange keys is by email. When the public key as armored text is part of the email body, Mailvelope can detect the key and mark it with an overlay as is the case with encrypted messages:
On clicking, the Mailvelope options dialog opens and the key is automatically imported.
Work on the Firefox version of Mailvelope has progressed and the feature set is now almost identical to the Chrome extension. Only the decrypt inline scenario is currently not feasible due to technical limitations. Instead, the Firefox add-on will always display decrypted messages in a pop-up window. Also, the performance needs further improvements before we can officially release the Firefox add-on.
Find the latest packages for both platforms in the releases section on GitHub.
Among others, Mailvelope now generates 2048-bit RSA keys by default, fixes wrong encoding of non-ASCII characters in messages and adds a reference to Mailvelope in the PGP header comment. See changelog for a complete list of changes.
Mailvelope v0.7.0 for Chrome is now available in the Chrome Web Store.
Mailvelope v0.6 is released today with a major redesign focusing on security. An audit done by Cure53 started end of December 2012 and evaluated Mailvelope’s security implementation and its security design aspects. In the course of two months we worked together with Cure53 on new concepts to prevent any form of leak of sensitive user data and at the same time do not degrade the user experience. The complete penetration report may be reviewed here.
Highlights of this new release include:
See also the security section in the documentation for more details.
We would like to thank the Open Technology Fund (RFA) for sponsoring the security audit. Without this funding the optimizations in the new release of Mailvelope would not have been possible. Thanks go also to Mario Heiderich and Krzysztof Kotowicz from Cure53 for their contributions.