User Tools

Site Tools


Accelerating Skylake 2D graphics

I recently upgraded my PC to a Skylake i5 (Core i5 6400), which has the new Intel graphics. However, 2D graphics was extremely slow on my 4k monitor. When I wanted to play a small webm, I could be sure Firefox would freeze; switching applications always took half a second. However, switching the acceleration method of the Intel driver from UXA (which was loaded according to Xorg.0.log) to SNA fixed that.

The following content for the file /etc/X11/xorg.conf.d/20-intel.conf fixed the issue:

Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "DRI" "3"
        Option "AccelMethod" "sna"
2016-01-10 16:27 · gnrp

I'm back!

The message with the master thesis was there for quite a long time, and is outdated for several months now. Lots of things changed in my life, but I'm happy I'll finally have some time. A new markdowku release is on the way (to work on PHP 7), and more things are about to come. The calendar must be updated, etc.

2016-01-03 14:36 · gnrp

Stopping all my current projects

I'm sorry to announce this, but I have to stop all my work on my current projects. I haven't been doing anything about them for a few months, and writing currently my new thesis, it is impossible for me to continue a responsible development. I already pushed some changes, especially to Markdowku, but didn't make a release yet, since I don't want to do the support. I will come back to this once I finished my Master thesis, which should be some time around summer.

But, on the good side: I was just contacted by a person who wants to implement a nicer interface for Calendoku! So maybe with the next versin, you will have a much nicer overview than the current table!

2015-02-10 23:46 · gnrp

Why I don't use OTR

When you're communicating with a certain kind of people via Jabber/XMPP, you're often asked for encryption. I do use encryption, even end-to-end, but I don't use Off-The-Record Messaging (OTR), which is what most people assume, and I have reasons for that:

Perfect Forward Secrecy is uninteresting for me

I log every communication. More or less willingly, but I don't take special notes of things that are said, so chatlogs are an important source of
information for me. Most people do so as well. Since logs and keys are in most cases stored on the same storages, getting hold of the key also means getting hold of the chat logs.

I don't want to say Perfect Forward Secrecy (PFS) is useless, I'm just saying that for XMPP this is an attack scenario I don't see myself in.

OTR messes up multiple clients/resources

I often use several clients simultaneously connecting to one account - my
notebook, my desktop computer, my mobile phone. XMPP is perfectly able to handle multiple resources, and it is one of the excellent features. But with OTR, the ability to use multiple clients in a sensible way is broken. Apart from OTR handshakes going terribly wrong when multiple clients are responding to a message (though I've been told this is a thing from the past), you cannot pass a connection to other clients. Even further, when one client goes offline and the message is directed to another one, the message is
unreadable without the sender noticing. Or even having another client with a different key breaks readable messages.

OTR has no network behind it

Even though libotr, the most common library used for OTR (or the only one?), in the background uses libgcrypt, the library handling the crypto behind GnuPG, it uses its own key material, and the only frontend to this being the XMPP client. There is no clean and easy way to exchange keys or trust between XMPP clients, so if you change your client because your old one is outdated (guess who had this recently), you have to reestablish all validations again, and create new keys. Even though, all in all, the crypto behind OTR and the mechanisms would allow you to use your PGP key and the PGP trust network. You could use the web of trust which has been established for decades and has a huge amount of users. It is just not done yet.

OTR cannot handle offline messages

The most important point to me is: OTR does not encrypt offline messages. About ten years ago, I tried to get people away from the MSN messenger which couldn't at that time handle offline messages. And nowadays, technical folks are willingly refusing offline messages, since OTR cannot encrypt that. I don't refuse, and I often use offline messages, so OTR is useless for me.

It is clear that ensuring PFS with asynchronous communication is not easy, but why not just use non-PFS, but asynchronously encrypted connections for offline messages?

"There is no alternative to OTR"

There is an alternative to OTR: PGP. There is even an obsoleted XMPP extension specifying how PGP is implemented in XMPP. But PGP has drawbacks as well: On the one hand, it isn't as widely deployed as OTR (I think Pidgin and Adium the main reasons) and it doesn't have an included key exchange – you have to exchange keys prior to the communication with a tool handling your PGP keys.

Even though I don't like the “I don't like detail X, so I won't use it” approach, I think in this case it is appropriate. OTR doesn't give me the security I want (offline messages) without being userfriendly (multiple clients).

What now?

I still hope for somebody writing a combined encryption library, which uses the key material and network from PGP, and uses PGP for offline messages, but OTR for synchronous messages. If I have time (and the missing knowledge) to do so one day, I'll do, but until that time comes, I'll have to stick to GPG. There is no way to achieve a useful encryption with OTR with my setup.

Researching for this article, I also found this excellent article about the state of mobile XMPP in 2014. I highly recommend it to you to read, since a lot of issues with XMPP and their are explained.

2014-11-26 16:13 · gnrp

Calendoku v5a released!

Not really worth a message, but I just released a new version of calendoku which fixes several issues with timezone handling introduced in v5. Still, date/time handling in PHP is a mess. ;-)

2014-11-06 00:18 · admin

<< Newer entries | Older entries >>

start.txt · Last modified: 2014-02-18 22:41 by gnrp