GNOME Keysign 0.9.9

tl;dr: We have a new Keysign release with support for exchanging keys via the Internet.

I am very proud to announce this version of GNOME Keysign, because it marks an important step towards a famous “1.0”. In fact, it might be just that. But given the potentially complicated new dependencies, I thought it’d be nice to make sort of an rc release.

The main feature is a transport via the Internet. In fact, the code has been lurking around since last summer thanks to Ludovico’s great work. I felt it needed some massaging and more gentle introduction to the code base before finally enabling it.

For the transport we use Magic Wormhole, an amazing package for transferring files securely. If you don’t know it yet, give it a try. It is a very convenient tool for sending files across the Internet. They have a rendezvous server so that it works in NATted environments, too. Great.

You may wonder why we need an Internet transport, given that we have local network and Bluetooth already. And the question is good, because initially I didn’t think that we’d expose ourselves to the Internet. Simply because the attack surface is just so much larger and also because I think that it’s so weird to go all the way through the Internet when all we need is to transfer a few bytes between two physically close machines. It doesn’t sound very clever to connect to the Internet when all we need is to bridge 20 centimetres.

Anyway, as it turns out, WiFi access points don’t allow clients to connect to each other 🙁 Then we have Bluetooth, but it’s still a bit awkward to use. My impression is that people are not satisfied with the quality of Bluetooth connections. Also, the Internet is comparatively easy to use, both as a programmer and a user.

Of course, we now also have the option to exchange keys when not being physically close. I do not recommend that, though, because our security assumes the visual channel to be present and, in fact, secure. In other words: Scan the barcode for a secure key signing experience. Be aware that if you transfer the “security code” manually via other means, you may be compromised.

With this change, the UX changes a bit for the non-Internet transports, too. For example, we have a final page now which indicates success or failure. We can use this as a base for accompanying the signing process further, e.g. sign the key again with a non-exportable short-term signature s.t. the user can send an email right away. Or exchange the keys again after the email has been received. Exciting times ahead.

Now, after the wall of text, you may wonder how to get hold of this release. It should show up on Flathub soon.

GNOME Keysign 0.9.8 released

It’s been a while after my last post. This time, we have many exciting news to share. For one, we have a new release of GNOME Keysign which fixes a few bugs here and there as well as introduces Bluetooth support. That is, you can transfer your key with your buddy via Bluetooth and don’t need a network connection. In fact, it becomes more and more popular for WiFis to block clients talking to each other. A design goal is (or rather: was, see down below) to not require an Internet connection, simply because it opens up a can of worms with potential failures and attacks. Now you can transfer the key even if your WiFi doesn’t let you communicate with the other machine. Of course, both of you need have to have Bluetooth hardware and have it enabled.

The other exciting news is the app being on Flathub. Now it’s easier than ever to install the app. Simply go to Flathub and install it from there. This is a big step towards getting the app into users’ hands. And the sandbox makes the app a bit more trustworthy, I hope.


flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.gnome.Keysign

The future brings cool changes. We have already patches lined up that bring an Internet transport with the app. Yeah, that’s contrary to what I’ve just said a few paragraphs above. And it does cause some issues in the UI, because we do not necessarily want the user to use the Internet if the local transport just works. But that “if” is unfortunately getting bigger and bigger. So I’m happy to have a mix of transports now. I’m wondering what the best way is to expose that information to the user, though. Do we add a button for the potentially privacy invading act of connecting to the Internet? If we do, then why do we not offer buttons for the other transports like Bluetooth or the local network?

Anyway, stay tuned for future updates.

GNOME Keysign 0.9 released

Oh boy, it’s been a while that we’ve released GNOME Keysign 0.9. We changed quite a few things since last time I’ve reported but the most visible change are the new widgets which I already announced last time. Now it should be much easier to make changes with the GUI and experiment with designs.

Other changes include less visible things like the ability to run the program in a VM. We use gtksink now which not only reduces the amount of code we have to maintain but also makes it easier for us to maintain compatibility with different display servers. Similarly, we don’t use the v4l2src but rather a autovideosrc hoping that it will be more compatible with other platforms.

If you want to try to new version, the instructions in the README should get you going:

pip install --user 'git+https://github.com/GNOME-Keysign/gnome-keysign.git#egg=gnome-keysign'

Alternatively, you may try the Debian or openSuSE package. The Flatpak is still work in progress as we still need to figure out how to work with GnuPG running on the host.

The future will bring exciting changes, too. I plan for i18n support and more Python 3 compatibility.

DFN Workshop 2015

As in the last few years, the DFN Workshop happened in Hamburg, Germany.

The conference was keynoted by Steven Le Blond who talked about targeted attacks, e.g. against dissidents. He mentioned that he already presented the content at the USENIX security conference which some people think is very excellent. He first showed how he used Skype to look up IP addresses of his boss and how similarly targeted attacks were executed in the past. Think Stuxnet. His main focus were attacks on NGOs though. He focussed on an attacker sending malicious emails to the victim.

In order to find out what attack vectors were used, they contacted over 100 NGOs to ask whether they were attacked. Two NGOs, which are affiliated with the Chinese WUC, which represents the Uyghur minority, received 1500 malicious emails, out of which 1100 were carrying malware. He showed examples of those emails and some of them were indeed very targeted. They contained a personalised message with enough context to look genuine. However, the mail also had a malicious DOC file attached. Interestingly enough though, the infrastructure used by the attacker for the targeted attacks was re-used for several victims. You could have expected the attacker to have their infrastructure separated for the various victims, especially when carrying out targeted attacks.

They also investigated how quickly the attacker exploited publicly known vulnerabilities. They measured the time of the malicious email sent minus the release date of the vulnerability. They found that some of the attacks were launched on day 0, meaning that as soon as a vulnerability was publicly disclosed, an NGO was attacked with a relevant exploit. Maybe interestingly, they did not find any 0-day exploits launched. They also measured how the security precautions taken by Adobe for their Acrobat Reader and Microsoft for their Office product (think sandboxing) affected the frequency of attacks. It turned out that it does help to make your software more secure!

To defend against targeted attacks based on spoofed emails he proposed to detect whether the writing style of an email corresponds to that of previously seen emails of the presumed contact. In fact, their research shows that they are able to tell whether the writing style matches that of previous emails with very high probability.

The following talk assessed end-to-end email solutions. It was interesting, because they created a taxonomy for 36 existing projects and assessed qualities such as their compatibility, the trust-model used, or the platform it runs on.
The 36 solutions they identified were (don’t hold your breath, wall of links coming): Neomailbox, Countermail, salusafe, Tutanota, Shazzlemail, Safe-Mail, Enlocked, Lockbin, virtru, APG, gpg4o, gpg4win, Enigmail, Jumble Mail, opaqueMail, Scramble.io, whiteout.io, Mailpile, Bitmail, Mailvelope, pEp, openKeychain, Shwyz, Lavaboom, ProtonMail, StartMail, PrivateSky, Lavabit, FreedomBox, Parley, Mega, Dark Mail, opencom, okTurtles, End-to-End, kinko.me, and LEAP (Bitmask).

Many of them could be discarded right away, because they were not production ready. The list could be further reduced by discarding solutions which do not use open standards such as OpenPGP, but rather proprietary message formats. After applying more filters, such as that the private key must not leave the realm of the user, the list could be condensed to seven projects. Those were: APG, Enigmail, gpg4o, Mailvelope, pEp, Scramble.io, and whiteout.io.

Interestingly, the latter two were not compatible with the rest. The speakers attributed that to the use of GPG/MIME vs. GPG/Inline and they favoured the latter. I don’t think it’s a good idea though. The authors attest pEp a lot of potential and they seem to have indeed interesting ideas. For example, they offer to sign another person’s key by reading “safe words” over a secure channel. While this is not a silver bullet to the keysigning problem, it appears to be much easier to use.

As we are on keysigning. I have placed an article in the conference proceedings. It’s about GNOME Keysign. The paper’s title is “Welcome to the 2000s: Enabling casual two-party key signing” which I think reflects in what era the current OpenPGP infrastructure is stuck. The mindsets of the people involved are still a bit left in the old days where dealing with computation machines was a thing for those with long and white beards. The target group of users for secure communication protocols has inevitably grown much larger than it used to be. While this sounds trivial, the interface to GnuPG has not significantly changed since. It also still makes it hard for others to build higher level tools by making bad default decisions, demanding to be in control of “trust” decisions, and by requiring certain environmental conditions (i.e. the filesystem to be used). GnuPG is not a mere library. It seems it understands itself as a complete crypto suite. Anyway, in the paper, I explained how I think contemporary keysigning protocols work, why it’s not a good thing, and how to make it better.

I propose to further decentralise OpenPGP by enabling people to have very small keysigning “parties”. Currently, the setup cost of a keysigning party is very high. This is, amongst other things, due to the fact that an organiser is required to collect all the keys, to compile a list of participant, and to make the keys available for download. Then, depending on the size of the event, the participants queue up for several hours. And to then tick checkboxes on pieces of paper. A gigantic secops fail. The smarter people sign every box they tick so that an attacker cannot “inject” a maliciously ticked box onto the paper sheet. That’s not fun. The not so smart people don’t even bring their sheets of paper or have them printed by a random person who happens to also be at the conference and, surprise, has access to a printer. What a gigantic attack surface. I think this is bad. Let’s try to reduce that surface by reducing the size of the events.

In order to enable people to have very small events, i.e. two people keysigning, I propose to make most of the actions of a keysigning protocol automatic. So instead of requiring the user to manually compare the fingerprint, I propose that we securely transfer the key to be signed. You might rightfully ask, how to do that. My answer is that we’ve passed the 2000s and that we bring devices which are capable of opening a TCP connection on a link local network, e.g. WiFi. I know, this is not necessarily a given, but let’s just assume for the sake of simplicity that one of our device we carry along can actually do WiFi (and that the network does not block connections between machines). This also prevents certain attacks that users of current Best Practises are still vulnerable against, namely using short key ids or leaking who you are communicating with.

Another step that needs to be automated is signing the key. It sounds easy, right? But it’s not just a mere gpg --sign-key. The first problem is, that you don’t want the key to be signed to pollute your keyring. That can be fixed by using --homedir or the GNUPGHOME environment variable. But then you also want to sign each UID on the key separately. And this is were things get a bit more interesting. Anyway, to make a long story short: We’re not able to do that with plain GnuPG (as of now) in a sane manner. And I think it’s a shame.

Lastly, sending the key needs to be as “zero-click” as possible, too. I propose to simply reuse the current MUA of the user. That sounds easy, but unfortunately, it’s only 2015 and we cannot interact with, say, Evolution and Thunderbird in a standardised manner. There is xdg-email, but it has annoying bugs and doesn’t seem to be maintained. I’m waiting for a sane Email-API. I mean, Email has been around for some time now, let’s now try to actually use it. I hope to be able to make another more formal announcement on GNOME Keysign, soon.

the userbase for strong cryptography declines by half with every additional keystroke or mouseclick required to make it work

— attributed to Ellison.

Anyway, the event was good, I am happy to have attended. I hope to be able to make it there next year again.

GNOME at FSCONS14 in Gothenburg, Sweden

I was glad to be invited to FSONCS 2014 in Gothenburg, Sweden. Remember that this is also the place for next year’s GUADEC! This year’s FSCONS was attended by around 150 people or so. I guess it was a bit less. That might not sound like a lot, but it’s a very cool event with many interesting people and talks.

We, GNOME, had a presence at the event due to me bringing the EventsBox and T-Shirts to Gothenburg. It was quite a trip, especially with those heavy boxes…

The first keynote of the conference was given by Karl Fogel. He declared the end of copyright in 1993. He imagined copyright as a tree whose bottom has been chopped off, but the, the top hasn’t noticed that just yet. He put copyright on a timeline and drew a strong relation to the printing press. He claimed that in the United Kingdom, a monopoly used to control who prints and distributes books and it then transferred to a differently shaped monopoly which involved the actual authors. These could then transfer their rights to printers. He went on with ranting about the fact that nowadays you cannot tip the author for their (free) work. He appealed to the authors of f-droid or the firefox mobile app market to integrate such a functionality. Overall it was an interesting talk with many aspects. He is a talented speaker.

The second keynote was given by Leigh Honeywell. She talked about communities and community building. She said that she got most of the ideas presented in her talk from Sumana Harihareswara‘s “Models we use to change the world”. During her talk she referred to her experiences when founded the HackLabTO Hackerspace after having attended the CCCamp 2007. She basically shared models of understanding the community and their behaviour. The Q&A session was inspiring and informative. Many questions about managing a community were asked and answered.

Another interesting talk was given by Guilhem Moulin who went on to talk about Fripost. It is a democratic email service provider from Sweden. He gave a bit of an insight regarding the current Email usage on today’s Internet. He claimed that we have 2.7 billion internet users and that the top three email service providers accumulate roughly a third of this population. His numbers were 425 million for GMail, 420 million for Hotmail, and 280 million for Yahoo. All these companies are part of PRISM, he said, which worried him enough to engage with Fripost. In fact, he became a board member after having been a user and a sysadmin. As someone who operates a mail server for oneself and others with similar needs, I was quite interested in seeing concentrated efforts like this. Fripost’s governance seems to be interesting. It’s a democratic body and I wonder how to thwart malicious subversion. Anyway, the talk was about technical details as to how to create your own fripost.org. So I can only encourage to run your own infrastructure and found structures that care about running ecosystem. A memorable quote he provided to underpin this appeal is attributed to Schneier: “We were safer when our email was at 10,000 ISPs than it was at 10“.

My talk went sufficiently well. I guess I preached to the choir regarding Free Software. I don’t think I needed to convince the people that Free Software is a good thing. As for convincing the audience that GNOME is a good thing, I think I faced a big challenge. Some of the attendees didn’t seem to be very enthusiastic about their desktop which is great. But some others were more in the, what I would call, old school category using lynx, xautoscreenlock, and all that stuff from the 90s. Anyway, we had a great session with many questions from the audience such that I couldn’t even go through my slides.

I had a lightning talk about signing OpenPGP keys using GNOME Keysign. I probably need to write up a separate blog post for that. In short, I mentioned that short key IDs are evil, but that long key IDs are also problematic. Actually, using keyservers is inherently problematic and should be avoided. To do so, I showed how I transfer a key securely and sign it following best practices (thanks to Andrei for an initial version!). Bastian was nice enough to do the demo with me. We needed to cheat a little though, as currently, they key is transferred using the WiFi network you are on. The WiFi, however, didn’t allow us to create a TCP connection to each other. We thus opened a WiFi hotspot and used that. I think this would be a useful feature.

The last talk of the conference was given by Hans Lysglimt from Norway. He is, among other things, a politician, an activist, and an entrepreneur who founded an email service. His runbox has around 1000000 accounts and 30000 paid subscriptions, so it’s fairly big, compared to Fripost at least. Again, running email services myself, I found it interesting to listen to the stories he had to tell. His story was that he received a gag order for running his commercial email service provider. It remained unclear whether it was send because of his interview with Julian Assange or not.

Interestingly, he didn’t seem to have received many correct subpoenas in the sense that they were Norwegian court orders. However, in one case the American authorities went through the Norwegian legal system which he found funny in itself because the two legal system were not very similar. He eventually mentioned that every email service provider has at least one gag order, either an implicit or and explicit one. Ultimately, he concluded that you cannot trust a corporation.

FSCONS is an interesting event. Their manifesto is certainly impressive. I am glad to have visited and I am looking forward to visiting again. It is very atmospheric, very relaxed, and friendly. A very nice place to be.

Creative Commons Attribution-ShareAlike 3.0 Unported
This work by Muelli is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.