vanitasvitae's blog

Just another FSFE Fellowship Blogs site

Using Emoji for fingerprint verification

May 6th, 2017

The messaging app Telegram recently introduced end-to-end encrypted voice calls. As most of you probably know, encryption without verification is pretty useless since there is the risk of man-in-the-middle attacks. I don’t want to get too much into details about this. The point I want to make is, that you should verify your partners fingerprint (hash of the used key) in order to be secure.

The interesting part of Telegrams new feature is the way they verify fingerprints. Traditionally you are presented with a String of (typically hexadecimal – 0-9,A-F) characters. In the case of Conversations the fingerprint are 64 hexadecimal characters. Telegram on the other hand introduced the way of displaying 4 out of a set of 333 emojis (1). Note that this is only used to verify that the current voice call is secure. The next call would have a different fingerprint, so keep in mind, that we are talking about two different use cases here.

Still, how do those two methods compare? Could we use emoji in conversations to verify the fingerprint of identity keys?

With telegrams emoji encoding, there are 333⁴ = 12.296.370.321 possible hash values. This is tiny compared to the number of possibilities with the conventional fingerprint encoding (64 hex characters), which sum up to 16⁶⁴ = 115.792.089.237.316.195.423.570.985.008.687.907.853.269.984.665.640.564.039.457.584.007.913.129.639.936 unique hash values. This is far more secure than the system used by telegram. To be precise, it is 9.416.769.844.639.765.662.078.012.249.277.305.077.454.163.692.443.706.456.867.173.918.282 times more secure (theoretically).

But could we use emoji in eg. Conversations?

Lets say, we want to use emojis for fingerprint verification without trading away security. We’d have to display 31 emojis in order to be as secure as displaying 64 hex chars. Since most people are more familiar with numbers and the letters A-F, I doubt that this brings any benefits (we just cut the length of the string in half).

But what if we chose from a bigger set of emojis?

Lets say we want the fingerprint to be as short as the one in telegram (4 characters), but have the same security properties as the conventional 64 digit hex string. In order to encode the same amount of information in 4 symbols as we could in 64 hex characters, we’d have to use a pool of 18.446.744.073.709.551.616 symbols. Unfortunatelly there aren’t so many characters, let alone emojis.

But what would be the middle ground?

If we want our fingerprint to be 16 characters long, our character pool would be 65536 symbols. Thats the whole unicode space. Since there are many unicode characters that look alike and there are also a lot of “holes” in the unicode space, there are fewer usable characters.

In conclusion, it is not really possible/valuable to use emojis for fingerprint representation without trading away security.

(1): https://core.telegram.org/techfaq#q-how-are-voice-calls-authenticated

Attack of the Regulators

March 27th, 2017

Recently, the german “Bundesnetzagentur” (the German Federal Network Agency) contacted over 100 developers of XMPP (Jabber) clients in order to ask them to register their “services”. This is justified with section 6 of the German Telecommunications Act. Clients like eg. Xabber that are working on a server-client principle are considered a “service” and therefore have to be registered. That’s why Redsolution, the developers of Xabber received official mail, despite the fact that they are located in the Sowjet Union.

What does this mean? Will every developer of a chat client have to register in the future? How about the people that on the burden of running a free chat server? Also, does this also apply on computer games that include a chat functionality? What about the countless other ways to communicate over the internet that I forget?

Why would the Bundesnetzagentur do this? Have they simply not thought long enough about this, or do they simply not know better? What and how do they want to regulate? Is this the beginning of the end of the open XMPP protocol? What about other developers of eg. IRC, Slack or Matrix? Do they have to fear getting contacted too? Why are old people, that do not understand how the Internet works and what a client is allowed to regulate around? What can we do about this? And how can we raise awareness for the problematic of incompetent officials?

Similarly the “Kommission für Zulassung und Aufsicht” (ZAK, Commission for Authorization and Supervision) contacted the German Twitch and Youtube Stars “Piet Smiet”. In the opinion of the ZAK, everyone who is streaming and has more than 500 viewers is in need of a fee-based license. Such a license costs between 1.000 and 10.000 euros.

Again, why are German officials so ignorant and hellbent on destroying the simple and free world wide web? What steps can we take to stand up against unnecessary regulations?

Questions about questions…

 

Sources:

https://www.golem.de/news/meldepflicht-bundesnetzagentur-will-hundert-jabber-clients-regulieren-1703-126929.html

https://twitter.com/Xabber_XMPP/status/844865634672435200

https://www.golem.de/news/piet-smiet-alle-twitch-kanaele-sind-kostenpflichtiger-rundfunk-1703-126928.html

OMEMO

January 23rd, 2017

Recently there was a lot of news coverage of an alleged „backdoor“ in WhatsApp, the proprietary messaging application owned by Facebook. WhatsApp deployed OpenWhisperSystem’s Signal-protocol roughly a year ago. Now a researcher showed, that WhatsApp’s servers are able to register a new device key for a user, so that messages that the user did not read yet (the ones with only one checkmark) are re-encrypted for the new key, so they can be read by WhatsApp (or whoever registered the key). There were a lot of discussions going on about whether this is a security flaw, or careful design.

I also read a lot of articles suggesting alternatives to WhatsApp. Often mentioned was of course Signal, a free open source messenger by OpenWhisperSystems, the creators of the Signal-protocol, which does not suffer from WhatsApps “vulnerability”. Both WhatsApp and Signal share one major flaw: Both create a “walled garden” for their users. That means that you can only write WhatsApp messages to other WhatsApp users. Same goes for Signal. Since Signal depends on proprietary Google libraries, it cannot be used on mobile phones without Google Play services.

Every now and then the news mention another alternative, the XMPP network.

Conversations is a free libre XMPP client for Android, which introduced the OMEMO protocol for end-to-end encryption roughly two years ago. OMEMO is basically the Signal-protocol adapted to XMPP. Since there are many different XMPP servers that can be used with many different clients, the user has a choice, which software they want to use to communicate to their friends. The issue is, there are not too many clients supporting OMEMO at the moment. But what clients are able to do OMEMO at the moment?

For Android there is Conversations of course and very recently ChatSecure for iOS was released in version 4, which brought OMEMO support. So it looks good on the mobile front (Sorry WindowsPhone).

For the desktop there is Gajim, an XMPP client written in python, which offers OMEMO support as a plugin. This works well on Linux and Windows. I admit, this is not a lot compared to OTR or GPG – but wait, there is more ;)

Currently I am writing on my bachelors thesis about the OMEMO protocol. As part of this, I am working on a Smack module that hopefully will enable messenger apps based on the Smack library (eg. Xabber, Zom, Jitsi, Kontalk…) to encrypt messages with OMEMO.

Simultaneously another student is developing a Pidgin plugin and yet another one is implementing OMEMO for the console based XMPP client Profanity. You can find a quick overview of the state of OMEMO deployment on https://omemo.top.

Vanitasvitae

Starting to use the Fellowship Card

December 15th, 2016

I recently became a fellow of the FSFE and so I received a nice letter containing the FSFE fellowship OpenPGP smartcard.

After a quick visual examination I approved the card to be *damn cool*, even though the portrait format of the print of it still confuses me when I look at it. I especially like, how optimistically many digits the membership number field has (we can do it!!!). What I don’t like, is the non-https link on the bottom of the backside.

But how to use it now?

It took me some time to figure out, what that card exactly is. The FSFE overview page about the fellowship card misses the information, that this is a OpenPGP V2 card, which might be handy when choosing key sizes later on. I still don’t know, whether the card is version 2.0 or 2.1, but for my usecase it doesn’t really matter. So, what exactly is a smart-card and what CAN I actually do with it?

Well, OpenPGP is a system that allows to encrypt and sign emails, files and other information. That is and was nothing new to me, but what actually was new to me is the fact, that the encryption keys can be stored elsewhere than on the computer or phone. That intrigued me. So why not jump right into it and get some keys on there? – But where to plug it in?

My laptop has no smart-card slot, but there is that big ugly slit at one side, that never really came to value for me, simply because most peripherals that I wanted to connect to my computer, I connected via loved USB. It’s an ExpressCard slot. I knew that there are extension cards that can be fit in there, so they aren’t in the way (like eg. a USB dongle would be). There must be smart-card readers for ExpressCards, right? Right. And since I want to read mails when I’m on a train or bus, I’d find it convenient, when the card reader vanishes inside my laptop.

So I went online and searched for ExpressCard smart-card readers. I ended up buying a Lenovo Gemplus smart-card reader for about 25€. Then I waited. After half an hour I asked myself, if that particular device would work well with GNU/Linux (I use Debian testing on my ThinkPad), so I did some research and reassured me, that there are free drivers. Nice!

While I waited for my card to arrive, I received another letter with my admin pin for the card. Just for the record ;)

Some days later the smart-card reader arrived and I happily shoved it into the ExpressCard slot. I inserted the card and checked via

gpg –card-status

what’s on the card, but I got an error message (unfortunately I don’t remember what exactly it was) about that there was no card available. So I did some more research and it turns out I had to install the package

pcscd

to make it work. After the installation, my smart-card was detected, so I could follow the FSFEs tutorial on how to use the card. So I booted into a live Ubuntu that I had laying around, shut off the internet connection, realized that I needed to install pcscd here as well, reactivated the internet, installed pcscd and disconnected again. At that point in time I wondered, what exact kind of OpenPGP card I had. Somewhere else (forgot where) I read, that the fellowship card is a version 2.0 card, so I could go full 4096 bit RSA. I generated some new keys, which took forever! While I did so, I wrote some nonsense stories into a text editor to generate enough entropy. It still took about 15 minutes for each key to generate (and a lot of nonsense!). What confused me, was the process of removing secret keys and adding them back later (see the tutorial.)

But I did it and now I’m proud owner of a fully functional OpenPGP smart-card + reader. I had some smaller issues with an older GPG key, that I simply revoked (it was about time anyway) and now everything works as intended. I’m a little bit sad, because nearly none of my contacts uses GPG/PGP, so I had to write mails to myself in oder to test the card, but that feel when that little window opens, asking me to insert my card and/or enter my pin pays up for everything :)

My main usecase for the card became signing git commits though. Via

git commit -S -m “message”

git commits can be signed with the card (works with normal gpg keys without a card as well)! You just have to add your keys fingerprint to the .gitconfig. Man, that really adds to the experience. Now every time I sign a commit, I feel as if my work is extremely important or I’m a top secret agent or something. I can only recommend that to everyone!

Of course, I know that I might sound a little silly in the last paragraph, but nevertheless, I hope I could at least entertain somebody with my first experiences with the FSFE fellowship card. What I would add to the wish list for a next version of the card is a little field to note the last digits of the fingerprint of the key thats stored on the card. That could be handy for remembering the fingerprint when there is no card reader available. Also it would be quite nice, if the card was usable in combination with smart-phones, even though I don’t know, how exactly that could be accomplished (maybe a usb connector on the card?)

Anyways that’s the end of my first blog post. I hope you enjoyed it. Btw: My GPG key has the ID 0xa027db2f3e1e118a :)

Edit: This is a repost from october. In the mean time, I lost my admin pin, because I generated it with KeePassX and did not click on “accept” afterwards. That’s a real issue that should be addressed by the developers, but thats another story. I can still use the card, but I can’t change the key on it, so some day I’ll have to order a new card.

vanitasvitae