vanitasvitae's blog


Archive for May, 2017

Last week of GSoC Community Bonding

Friday, May 26th, 2017

This is my report for the last week of community bonding. On next tuesday the coding phase officially begins \o/.

I spent my week like I did the one before; writing tests, increasing the codecoverage of my Smack OMEMO module. Today the coverage finally reached the same level as the main codebase, meaning my PR wouldn’t decrease the percentage anymore. Apart from that I’ve read some tips on java.nio usage for file transfer and made myself more familiar with its non-blocking IO concepts.

Throughout the week I took the one or other chance to distract myself from work by pariticipating in OMEMO related discussions on the standards mailing list. I’m quite happy, that there’s a vital discussion on the topic which seems to have a solution in prospect which is acceptable for everyone. Specifying the OMEMO XEP in a way that enables implementations using different crypto libraries is definitely a huge step forward which might bring a broader adoption without leaving those who pioneered and developed the standard standing in the rain (all my subjective opinion). I was really surprised to see developers of the Matrix project participating in the discussion. That reminded me of what the spirit of floss software really is :)

I plan to spent the last days before the coding phase sketching out my projects structure and relaxing a little before the hard work begins. One of my goals is to plan ahead and I really hope to fulfill this goal.

Happy Hacking :)

Vanitasvitae

GSoC: Second, third week of community bonding

Saturday, May 20th, 2017

Hi all!

This is my report for the second, as well as the first half of the third week of GSoC community bonding, which I spent again working on finalizing my OMEMO code.

I dug deeper into writing test cases, mainly integration tests and I found quite a lot of small, undetectable bugs this way (Yay!). This strengthens my plan to work test driven during my GSoC project. The OMEMO code I currently work on was started as part of my bachelor thesis about 4 to 5 months ago and at this time, I was more concerned about having working code in the end, so I wrote no tests at all. Deploying test cases AFTER the code is already written is not only a tideous task, but its also often very difficult (because the code is not structured properly). So I learned my lesson the hard way :D

During testing I also found another bug in an XMPP server software, which prevents Smack from creating accounts on the server on the fly. Unfortunatelly this bug will not get fixed anymore for the version I use (installed from debian testing repository, which I thought was *reasonable* new), which keeps me from doing proper testing the way its meant to be done. I don’t have the time to compile the server software myselves. Instead, I work around this issue by creating the accounts manually everytime I run the test suite using a small bashscript.

I also had to deal with a really strange bug with file writing and reading. smack-omemo has a set of 4 integration tests, which all write data into a temporary directory. After each test, the directory is deleted to prevent tests influencing eachother. The issue was, that only the first test could read/write to the test directory. All subsequent tests failed for some reason. It took me a long time to notice, that there were two folders created (one in the working directory, another one in the subdirectory of the integration test framework). I am still not really sure what happened. The first folder was logged in all debug output, while files were written (by the first test) to the second filder. I guess it was caused by the temp directory being specified using a relative path, which messed up the tests, which were instanciated by the test framework using reflection. But I’m really not sure about this. Specifying the directory using an absolute path fixed the issue in the end.

Last but not least, me and Flow worked out some more details about my GSoC project (Implementing (encrypted) Jingle file transfer for Smack). The module will most likely be based upon java.nio to be scalable in the future. Flow also emphasized that the API should be as easy to use as possible, but at the same time powerful and extensible, which is a nice challenge (and probably a common one within the XMPP community). My initial plan was to create a XEP for OMEMO encrypted Jingle file transfer. We decided, that it would be of more value, to specify the XEP in a way, which allows arbitrary encryption techniques instead of being OMEMO exclusive.

Currently there is a little bit of tension in the community regarding the OMEMO specification. I really hope (and believe) there is a solution which is suitable of making everybody happy and I’m looking forward to participate in an open discussion :)

Happy hacking!

GSoC: First week of community bonding

Wednesday, May 10th, 2017

The first week of community bonding is nearly over and already it’s quite an experience for me. Me and Alameyo were very nicely welcomed by members of the igniterealtime project which really took care of making us able to jump right into the project.

I spent most of the time making myself more familiar with the Smack codebase by working on my OMEMO pull request, which comes closer and closer to a mergeable state. Currently I’m working together with my mentor Flo to make the API of the module as easy to use as possible. I learned the hard way, that singletons and generics are a pain when used together, but in the end it worked out quite well I’d say, although there is still some work left to do.

During the week, I also came across some bugs in XMPP server software, which were a great opportunity to come in contact with other developers outside of the igniterealtime project. Everybody was nice and helpful. Its really pleasant to work with the community.

Lastly, I also got in touch with some other GSoC students, which is super fun. I really enjoy meeting people from other countries and it turns out, that everybody puts their pants on the same way.

I’ll post updates roughly on a weekly basis to document the course of events. Untill then :)

Happy Hacking!

My GSoC introduction

Sunday, May 7th, 2017

Hi!

My name is Paul Schaub (vanitasvitae), I’m a computer science student from Münster, Germany, I’m 23 years old and right now I’m in my 8th semester.

I’m very close to getting my bachelors (undergraduate) degree with only one subject missing (Yay!). That’s why I got some spare time, which I am very happy to be able to spend as a GSoC (Google Summer of Code) student on the Smack project \o/!

 

In my free time, I’m involved in some free software projects mostly around Android apps. I’m currently one maintainer of the unofficial diaspora* app dandelion*. I also wrote the most likely unknown Android app EnigmAndroid which is a simulation of the Enigma machine.

 

My bachelors thesis was about implementing the OMEMO encryption protocol for the Smack library. The result is currently available as an open pull request (there’s still some work to do ). I chose this topic, because I believe that strong, easy to use encryption is very important for society. I’m very happy that the project worked out so great so far.

 

Within the GSoC, I’ll implement Jingle file transfer for Smack as well as finish up the OMEMO PR. Also I’ll try to find an elegant solution for OMEMO encrypted file transfer, which I’ll try to formalize into a (Proto-)XEP. Here you can find my GSoC proposal.

 

I’m always interested in making new contacts in the FOSS world, so if you have any questions or want to chat, don’t hesitate to contact me . You can find my contact information on my github page, but I’m also hanging out in the open_chat MUC.

 

Happy hacking!

Vanitasvitae

Using Emoji for fingerprint verification

Saturday, 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