OpenKeychain

OpenKeychain 5.1

OpenKeychain-Team — Wed, 27 Jun 2018 00:00:00 +0000

This month we released OpenKeychain version 5.1.

We have accumulated a bit of a backlog of improvements since our last release announcement. Some highlights:

Autocrypt

In version 5.0, we introduced support for Autocrypt. K-9 Mail since Version 5.4 uses this to automate the exchange of public keys. Other compatible clients include Enigmail and DeltaChat.

Elliptic Curve Cryptography

Version 4.9 completed support for modern keys based on Curve 25519. These keys offer stronger security guarantees and faster operations than RSA at smaller key sizes. OpenKeychain should now be able to work with all commonly used keys.

WKD

OpenKeychain now includes the Web Key Directory (WKD) mechanism. This automatically looks up keys on the provider domain when searching for an email address, if available. For example, searching for linus@kernel.org will automatically fetch the correct key from kernel.org, avoiding ambiguity from keyservers. Many thanks to Wiktor Kwapisiewicz for contributing this feature.

Improved USB support

OpenKeychain should now work correctly with Gnuk, Nitrokey and Ledger Nano S security tokens via USB, as well as the Yubikey 4. Shout outs to the guys at Nitrokey and Yubico for providing test devices!

Fix security issue

In version 5.1, we fixed a potential security issue with the external key status interface. We are not aware that this has been exploited in practice, users should still update to at least version 5.1 as soon as possible. You can find some details in our documentation of past vulnerabilities.

Install OpenKeychain

OpenKeychain is available on Google Play and F-Droid.

- Vincent and Dominik

Founding of COTECH

OpenKeychain-Team — Mon, 25 Jun 2018 00:00:00 +0000

With the friendly support of TU Braunschweig, COTECH was founded by Vincent Breitmoser, Leif Scheppelmann and Dominik Schürmann. Our company provides professional support for OpenKeychain and develops custom end-to-end encryption products.

OpenPGP/Autocrypt Library

We are currently in the process of developing an OpenPGP/Autocrypt library based on the OpenKeychain codebase. It will be available as a GPLv3 version for other Free Software projects, but also under a commercial license to be used in proprietary projects. It can be used in your Android apps, but also in other Java-based software, for example desktop or server applications. For inquiries, please contact us.

Consulting

COTECH offers a range of consulting services for security research and development. We provide professional support for OpenKeychain and consulting services for the design and implementation of real-world cryptographic protocols.

OpenPGP Considerations, Part III: Autocrypt and Encryption by Default

OpenKeychain-Team — Mon, 26 Feb 2018 00:00:00 +0000

(This is a cross-post from K-9 Mail Blog)

This blog post is the third in my series on design decisions made in the OpenPGP support in K-9 Mail. Following my first post on signed-only mails, and the second one on encrypted-only mails. This one focuses on Autocrypt, and in particular “encryption by default”.

Autocrypt Support and UI Improvements

In K-9 Mail version 5.400, OpenPGP encryption was changed to adhere to the Autocrypt specification. Most importantly, keys are now transparently exchanged between compatible clients, paving the way for truly transparent key management with no need for user interaction.

Another big change happened in the user interface: In message view display of crypto status has been greatly simplified - either a message was securely encrypted (green lock), encrypted with problems (grey lock with an X), or hasn’t been encrypted at all (grey struck-through lock). The warning overlays that were previously displayed when a message was deemed insecure are also gone; Those messages now simply don’t get a green lock.

The most important changes, I think, have been made to message composition. Firstly, the crypto dialog is no more, encryption can instead be enabled or disabled with a single click on the lock. The “three lock states” are also gone, recipients either can be encrypted to (small lock) or they can’t (no lock). If all recipients have verified keys in OpenKeychain, this will still be indicated by three green dots next to the lock, but generally the key status is featured much less prominently than before.

Consensual Encryption by Default

All of the changes mentioned above work towards getting out of the user’s way with the crypto as much as possible. In keeping with this idea, non-consensual encryption by default has been removed as a feature. I realize this breaks the workflows of a couple of users, for which I apologize. However, I believe that this is the only way forward for usable e-mail encryption. Please bear with me and read on for an explanation.

Before K-9 Mail 5.400, encryption using OpenPGP was enabled “opportunistically”, which meant that whenever end-to-end keys were available, the message would automatically be encrypted. Since K-9 Mail 5.400, encryption will be enabled in exactly these three scenarios:

When the user chooses to encrypt (with a single click).
When replying to an encrypted mail.
When the user, and all recipients, enabled “Autocrypt mutual mode”.

The reason for this change is that encrypting e-mail messages is not strictly an improvement: Encrypted messages cannot be viewed in all clients and especially web clients, full-text search is typically restricted, and if the user loses access to their keys there might be unintended loss of messages. Most e-mail apps also rely on plugins for encryption, which is always going to be less neatly integrated than first-party support. In short, the increase in confidentiality comes at a cost in compatibility, availability, and convenience.

Now, encryption of e-mail has so far been a very deliberate act - to be able to encrypt to anyone, the user would have to somehow manually obtain the key and import it in their key management app. In addition to that, extremely few people would even have keys, because dealing with encryption plugins is a pain. But between contacts who have Autocrypt-capable clients, making encryption available as an option will hopefully just work. This is super great, but it weirdly brings up a problem:

Many people have an appreciation for encrypting secret.doc or invoice.pdf when they send it - but that appreciation doesn’t extend to all messages. If someone installs an Autocrypt-capable OpenPGP extension so they can securely send or receive secret.doc, this should not be interpreted as consent that any message sent to them, regardless of importance, may as well be encrypted. Autocrypt wants to move on from traditional OpenPGP as a niche product. To do that, it has to be possible to use an Autocrypt-capable client for e-mail that signals availability of encryption, but doesn’t lead to an increasing number of messages in the mailbox with the compatibility issues that encryption currently incurs. If we want to target a wider audience, we need to take the user experience of all users into consideration, which clashes with the availability of an option to non-consensually encrypt by default.

This brings us back to the three scenarios listed above. In each of them, there is a clear responsibility for the choice to encrypt:

In the first scenario, a user takes immediate responsibility that an individual message is encrypted.
Slightly less immediately, replies in an encrypted thread will also be encrypted.
And the third scenario is consensus between users who not only have a key, but also signal that it’s ok to encrypt to them by default.

Users who feel like they can reliably handle encrypted mail are encouraged to enable “Autocrypt mutual mode” (available in K-9 Mail 5.500). If we ever get to a point where encrypted e-mails actually work seamlessly, perhaps this mode can be enabled by default. For everyone else, making encryption available by choice with a single click and transparent key management should hopefully be a huge improvement.

OpenPGP Considerations, Part II: Encrypted-Only Mails

OpenKeychain-Team — Mon, 30 Jan 2017 00:00:00 +0000

(This is a cross-post from K-9 Mail Blog)

This blog post is the second in my series on design decisions made in the OpenPGP support in K-9 Mail. Following my first post on signed-only mails, this one focuses on encrypted-only mails.

In contrast to signed-only mails, which are still a supported workflow, we believe that the sending of encrypted-only mails reduces the security of the ecosystem as a whole, which is why we decided to drop support for it altogether. This decision led to a number of reports from disgruntled users who had sent encrypted-only mails from earlier versions of K-9. We realize it sucks to have your workflow broken, so I will try to explain why we made this decision, and why we are unlikely to revert it.

The idea of encrypted-only mails is to send messages that are encrypted to the recipient’s public key, but not signed with the sender’s secret key. This provides weaker security properties than properly signed-then-encrypted mails, but it loses the requirement of having the signing key available on the sender side, which makes for a deceptively convenient and attractive workflow. Given more profound cryptographic thought however, it becomes clear that such messages introduce a cost to the ecosystem that greatly outweigh the benefits.

Use cases

There are two common arguments for encrypted-only mail:

No signing key on mobile

A commonly proposed use case for encrypted-only mail are users who don’t want to put their signing keys on their phone due to security concerns, but still want to send encrypted mail. This is a technical possibility after all, and some encryption - even without authentication - is surely better than no encryption.

Unfortunately, it’s not quite so easy.

To see why, let’s explore what it says about a message’s security if the sender doesn’t trust the sending device with their signing key: The sender themself knows that the message can only be read by the intended recipient, so from their perspective all seems well. But from the recipient’s perspective, it’s impossible to tell what is going on. If we regularly receive messages without signature, the user has no way to figure out whether a message was tampered with by an attacker, or sent without a signature because the sender just happened to not have their signing key available. So what is the mail client supposed to display to the user in this case? The answer is that we must treat missing signatures as insecure, since otherwise an attacker can simply strip signatures from all messages. And when they forge a message it will look just like many other messages the recipient saw in the past, encrypted but not signed.

Just like other insecure messages (sent from expired keys, revoked keys, insecure keys, or using insecure algorithms), an encrypted-only message is displayed in K-9 with a full-screen warning. Users are warned of the security issue at hand, and have to do an extra click to read message content. In this way, the message now looks more dangerous than a plaintext one.

But this warning dialog leads us straight to the issue of warning fatigue. The short version is, users pay very limited attention to any kind of warning message, and every time such a message is displayed to the user, it loses some of its impact. After only a few times of clicking through a warning message to see the message content, the extra click becomes part of the routine.

But for any kind of authentication to work, it is imperative that authentication failures happen as rarely as possible. The crux of sending encrypted-only mails is that on the receiving side, genuine mails end up in a state that responsible user agents must treat as an error, eroding its ability to warn the user about cryptographic problems. Even worse, these warnings aren’t actionable - there is nothing a user can do to fix the situation, the only possible option is to move on and read the message. In short, sending encrypted-only mails establishes receiving insecure mail as a common and harmless occurrence for recipients.

You can generate a key to use per device - keys are free, after all! But if you don’t trust a device with any signing key, you can’t send secure mails from it.

“Plausible deniability”

The second common argument comes from people who consider encrypted-only mails as “anonymous” mails in a sense, similar to not signing letters.

This idea of “deniability” comes from protocols like OTR and Signal, which go to great lengths to provide this property. Unfortunately, these tricks can’t simply be ported: They only work for session-based, synchronous communication. But what these protocols provide is deniable authentication, which is different from no authentication. No protocol for secure communication I’m aware of allows turning off authentication, in fact there is a clear trend in the cryptographic community towards the more integrated authenticated encryption.

Because e-mail as a protocol leaks a lot of metadata, any mail sent without extra measures to obfuscate this metadata is not going to be deniable, regardless of the encryption state of its content. There are projects that seek to reduce metadata leakage for general use of e-mail (like OnionMX or Panoramix), but those are hardly deployed.

And yet, sending anonymous mail is simple: Grab a Tor Browser, sign up for any free mail address, generate a key for this purpose only, send encrypted mail as usual. That way no one will know your name or identity, you can send more messages (from different addresses even), and the recipient will know they come from the same entity. You will also be able to prove it was you who sent the mail later on, which - provided you keep that secret key in a safe place and out of the cloud - nobody else can.

That said, Android is not a high-security environment! For actually important matters it is advisable to stick to a platform that was actually built for whistleblowing, like Globaleaks. But even there, you will receive a key code that serves to authenticate yourself, to safely communicate later on.

It is misguided to believe that not signing encrypted mails will provide any kind of deniability, and it is incorrect to assume that anonymity and authentication are incompatible properties.

So why do other implementations allow it?

The UI in many OpenPGP implementations for secure communication via mail has a “sign” and an “encrypt” button. This was the case in K-9 Mail as well, until version 5.200. A very common stance of OpenPGP implementations is to just give users the cryptographic operations, then let them make security considerations themselves, given more or less complete information about the system. But OpenPGP itself is a very general purpose cryptosystem, that can be used for all sorts of tasks besides communication, like package-signing or encryption of backups. The simple design of two checkboxes is the straightforward way of applying the OpenPGP message format to e-mail. But that doesn’t mean it’s a good idea to do so.

Conclusion

For the reasons outlined above, we dropped support for encrypted-only mails. We urge other mail clients to do the same.

K-9 Mail 5.200 with PGP/MIME support

OpenKeychain-Team — Wed, 04 Jan 2017 00:00:00 +0000

K-9 Mail 5.200 has been released, which finally supports the PGP/MIME standard. It also provides a new user interface for even easier end-to-end encryption.

Support for PGP/MIME required a lot of internal changes and extensions to K-9 Mail to get it working with OpenKeychain. Vincent Breitmoser did most of the work on this. He was able to work on it full-time for a year thanks to the generous funding of the Open Tech Fund. A huge thank you to them!

We also like to thank cketti, the maintainer of K-9 Mail, and all other contributors, especially Philip Whitehouse who contributed a lot of patches.

The new version should be available on Google Play and F-Droid shortly. If you can’t wait, go grab the APK from GitHub.

- Vincent Breitmoser, Dominik Schürmann

OpenPGP Considerations, Part I: Signed-Only Mails

OpenKeychain-Team — Thu, 24 Nov 2016 00:00:00 +0000

(This is a cross-post from K-9 Mail Blog)

I have been working for some time now on the OpenPGP support in K-9 Mail. At this point, I finished implementing basic OpenPGP functionality, which is now in the alpha channel and due for release soon. I also spent a lot of time thinking about use cases, user experience, and usability of OpenPGP as a protocol and as an ecosystem. I was lucky to meet people who would share their point of view on this subject, including fellow developers, activists, and both hardcore and casual users. Unfortunately, these groups of people often have conflicting views, and there is no consensus about the direction OpenPGP is going.

The OpenPGP implementation in K-9 Mail is opinionated, and some of the ideas and decisions are different from other implementations. Some decisions are not obvious to long-time users of OpenPGP implementations, or outright clash with their expectations. I spent considerable time arguing these decisions on our issue tracker, on our irc channel, and in person. This is a good thing - if I can’t argue my decisions, they probably aren’t reasonable. But I feel like I should make a better effort to keep everyone on the same page, which is why I’m going to write a series of blog posts about the thought processes and considerations that led to the design decisions made in K-9 Mail.

I’ll start in this post with one of the later changes I made:

Signed-Only Mails Considered Harmful

(I apologize for the section title, but it’s true!)

In a relatively recent pull request, I decided to demote signed-only mails from an encouraged workflow to a supported workflow. What this means is that everything related to signed-only mails has been moved into an opt-in feature. Without enabling this feature, the user will neither see the status of signed-only mails, nor will they find an option to send them.

Secure communication requires both authentication and confidentiality. It’s possible to get one without the other: You can send signed-only mails, giving you only authentication, and you can send encrypted-but-not-signed mails, giving you only confidentiality. I firmly believe that both of those are misfeatures, which stand in the way of getting the thing to be done into a usable state. The thing to be done with OpenPGP for email is secure communication. For today, I will stick to the former part, signed-only mails.

Signed-Only Mails are Useless

No, really. Signed-Only mails, for general communication, are useless. Consider a scenario where you know a user who usually signs their emails, and you receive an email from them with content that is reasonable in context. Now, what happens if that email is not signed? Or if the signature doesn’t check out? Be honest now: Would this trigger an actual reaction for you, in day-to-day emailing? Has it, in the past?

The answer for me is, if someone sends an email that is not signed but makes sense in context, I will not question the content. Even with a broken signature, especially on mailing lists, the assumption is going to be that the mail just broke on the way. If someone wants to send a secure e-mail to me, they will encrypt it.

There are times and places for signed text, and it’s nice that OpenPGP supports this. But in day-to-day communication, where you just want to communicate, it serves no purpose.

Signed-Only Mails are Not Free

So, what’s the issue? Signatures may not be very useful, but some people really like sending people signature.asc attachments! Where’s the harm in that?

The harm is that signed-only mails are not only not free, they come in fact at a very high cost. That cost is complexity. It is complexity in the implementation, complexity in the user interface, complexity in the ecosystem.

Complexity in the implementation is fine. Couple hundred, maybe a thousand lines of code, for handling detached signatures and displaying state of signed emails. Been there, done that.

Complexity in the user interface is bad. For most users, the bearable complexity for a “How secure am I?” indicator is two states: “You are safe”, and “You are not safe”. We’re already in trouble with handling expired or revoked keys, and insecure algorithms, but those aren’t things we can get rid of easily. An indicator state for authenticated but non-confidential communication introduces a whole set of states of “I have no idea what is going on” to everyone but the most technical of users. Right into the place where we really want to inform the user about important stuff, in a way that is as clear and concise as possible.

Complexity in the ecosystem is the worst. It’s fine that OpenPGP as a message format can do a lot of things that most users don’t understand or care about. But what we are building here, on top of this protocol, should be secure communication. Signatures are a thing that few people understand, that even less people really want to use, yet that many feel pressured into using uncomfortably or use as a point of pride because it feels kinda exclusive, but that is in the end so unreliable that its benefit is nothing short of questionable.

There is a name for this, plain and simple: it’s bloat. It’s bloat we’ve been dragging along in the OpenPGP user experience for far too long. It’s time we got rid of it.

- Vincent Breitmoser

German Study Published: “Usage of OpenPGP on Android”

OpenKeychain-Team — Mon, 19 Sep 2016 00:00:00 +0000

As a subcontractor, Vincent Breitmoser (OpenKeychain) and Dominik Schürmann (OpenKeychain/TU Braunschweig), participated in the Gpg4all project led by Intevation GmbH and g10 Code GmbH. The project has been published as a public tender and is funded by the German Federal Office for Information Security (BSI).

One part of this project was to create a study of the current state of OpenPGP support on Android. We defined requirements for OpenPGP implementations on mobile devices, in particular on the Android Operating System and provide an overview over currently available apps to evaluate if their functionality satisfies the requirements. Based on this evaluation, we propose several further development opportunities based on OpenKeychain.

We are happy to announce that the results of this study have now been published under the Creative Commons License (CC-BY-SA) on the BSI website (German only).

- Vincent Breitmoser and Dominik Schürmann

Free Fidesmo Cards for New Contributors

OpenKeychain-Team — Tue, 16 Aug 2016 00:00:00 +0000

Every now and then we receive pull requests from contributors which fix bugs, make improvements or even add a new feature to OpenKeychain. This is what open source is all about, and it’s what keeps us going. So we decided that we want to reward those awesome people who spend their time and effort making OpenKeychain the best app it can be.

Starting today, as a token reward we will send a free Fidesmo card with the OpenPGP applet preinstalled to new contributors! Just submit a (non-trivial) pull request, you are eligible once we merge it. To keep the bureaucratic overhead to a minimum, we will simply ask for an address to send the card to after we merge, and the card will be sent directly from our friends over at Fidesmo.

- Vincent Breitmoser and Dominik Schürmann

Cooperation with the Localization Lab

OpenKeychain-Team — Fri, 15 Apr 2016 00:00:00 +0000

Until today, translations of OpenKeychain were managed by me on Transifex. Due to my focus on developing OpenKeychain and producing code, I wasn’t able to coordinate the translation efforts in a good way or to improve the translation by myself.

Today, I am happy to announce that we now cooperate with the Localization Lab. That means that we moved the coordination and management of our translations on Transifex to their organization. The Localization Lab is a global community of volunteer translators who support the translation and localization of Internet freedom tools, such as OpenKeychain. They translate more than 30 tools into over 180 different languages and dialects and currently expand their translations of tools in Tagalog, Khmer, Vietnamese, Burmese, Laotian, Indonesian, Thai and Chinese (simplified and traditional scripts). The Localization Lab community is growing and this year will be coming together for community events, translation sprints and other fun activities that will push forward the localization of these tools. You can find out more about their efforts on www.localizationlab.org.

- Dominik Schürmann

Google Summer of Code 2016, and OpenKeychain 3.9: Performance Improvements and Text Handling

OpenKeychain-Team — Thu, 10 Mar 2016 00:00:00 +0000

Google Summer of Code 2016

We are happy to announce that we have been accepted as an organization for Google Summer of Code 2016! We had a very positive experience with GSoC in the past years, gaining new contributors and features, and we hope the outcome will be equally successful this year! Our issue tracker is already happily abuzz with students handing in their patches.

If you are a student and want to get paid for coding that feature you always wanted to see in OpenKeychain, check out our GSoC 2016 Page and get involved!

OpenKeychain 3.9

We released OpenKeychain 3.9 last thursday!

A few words on the major changes:

Performance

Compared to security, the performance of our code was never a huge priority for us. However, we received an increasing number of reports that the decryption and signing routines were really slow under certain circumstances. In this new release, we got rid of some bottlenecks and use better caching, which should lead to a significant speedup for all crypto operations.

Handling of Encrypted Text

An encrypted data file usually includes some amount of metadata on the encrypted content. This includes things like the filename of the encrypted file, a modification date, and a flag whether the data is plain text or binary. Until now, we mostly trusted this data - if it said it was text, we displayed it as text, if it said the content was binary, we treated it as binary, if there was a filename, we tried to guess the type by its file extension. This mostly works - encrypting a file.pdf will detect the filetype as pdf, and offer PDF Viewers in the list of apps to open the file with.

However, there is the special case of an encrypted text which is marked as binary, and also comes with no filename. With no information about the file content, we only supported saving the data and opening it as a generic binary file - for which no Apps usually exist to handle it. This is correct behavior - but not particularly helpful if the user knows that the data is just a text and simply wants to view it. Unfortunately, text data is incorrectly marked as binary quite often.

To improve on this situation, we now treat data where we have no better information about its content as plaintext, if it contains no invalid characters for an UTF-8 encoding. We hope this change works as intended in most cases.

- Vincent Breitmoser, Dominik Schürmann