Monday, December 8, 2008

LUKS on-disk-format revision 1.1.1

Today, I published a new minor revision of the LUKS on-disk-format specification. It contains clarifications with respect to IV/tweak reference points. Thanks to Michael Gorven for the suggestion.

It is available at new home of cryptsetup/LUKS at Google Code

Monday, December 1, 2008

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.

I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).

GridSelect is my answer to that. It brings up a 2D grid of windows in the center of the screen, and I can select a window with cursors keys. The window is delivered back to the caller of GridSelect, and for the moment the most useful thing it does for me is to raise and focus the selected window. The advantage over the presentation of Tabbed is that there is much more space for window titles, that are now not forced into a single row at the top of the screen, but can occupy multiple rows. Also navigating a 2D grid is also much faster than navigating a linear 1D structure.

GridSelect colorizes the cells according to the window class of displayed window. So, all windows with the same class get the same color, and after a while I start to remember which window class has which color. E.g., when I want my xchat window, I just have to search for light green, or if I want an emacs windows, I have to focus on dark violet.

Although GridSelect wasn't meant for inclusion into xmonad-contrib, dons was quick to merge it into the darcs repo. ATM I'm using the following key binding fragment:

((modMask, xK_f ), (gridselect defaultGSConfig) >>= (\w -> case w of
Just w -> windows (bringWindow w) >> focus w >> windows W.shiftMaster
Nothing -> return ())


There are a few ideas that I haven't found time to toy with. First I like the window arrangement to be more static. At the moment, the windows are sorted (by XMonad) according to its last use and GridSelect arranges them spiraling outwards in a diamond like pattern. Mentally, I can only keep track of the last two to three windows, so that I can blindly select them. For everything else, I have to read titles. It would be more helpful to give fixed spots to windows. Of course, windows get deleted and new windows pop up all the time, so probably it would be good to defragment and resort according to display time with a special key.

Substring search on window titles is another idea. As GridSelect uses cursors keys for the moment, the rest of the keyboard could be used to enter the string used in searching. GridSelect should then gray out the windows that do not contain the search term.

I guess I won't hack on these ideas immediately as GridSelect ATM does what it should do, namely lower the time that I spend searching for windows significantly.

Saturday, November 15, 2008

"A workaround for Bittorrent traffic shaping" or "bashing my ISP"

Recently, I found out that my ISP does traffic shaping with respect to Bittorrent traffic. After my clients sends the Bittorrent handshake, all packets from the respective TCP conversation were dropped, so the remote peer sees nothing of the following. That's not just a minor issue in quality of service, right? That's a breach of contract with respect to universal IP service agreements.

If you are subscribed to UPC in Vienna, this letter to my ISP might be interesting to you. Next to regular rhetoric that they should immediately stop that practice, they are also warned that otherwise I will get them in front of the national conciliation body for telecommunication (

If you are unlucky to be subscribed such brain dead ISPs, you can use Azureus to work around that.
  • Find out your public IP and ensure that there is some open/forwarded port in your firewall/router or whatever you may have. 
  • Get and setup up and Azureus.
  • Run TOR with its Socks proxy.
  • Launch Azureus
  • Azureus-Options-Connection: Enter the public port from before as Incoming TCP/UDP listen port.
  • Azureus-Options-Connection-Proxy Options: Tick "Enable proxying of tracker communication
  • Azureus-Options-Connection-Proxy Options: Tick "I have a SOCKS proxy", and enter the host/port combination of your Tor Socks proxy (most likely localhost:9050)
  • Azureus-Options-Connection-Transport Encryption: "Require encrypted transport" with Minimum encryption level "RC4"
  • Azureus-Options-Tracker-Client: Enter your public IP/port in the "Override Options".
That's it. You are ready to go, and override ANY bittorrent traffic shaping (at least the one that listens for bittorrent signature). The drawback is that your only able to communicate with other Bittorrent clients that know encryption. But that's better than no connection at all.

Monday, September 22, 2008

Counter-steganography research?

In the context of a national research fund, I recently stumbled across a project that deals with counter-steganography research. From an academic point of view, it is healthy to have security technology research and research trying to break these technologies. But when I had a closer look what kind of counter-steganography they were actually working on, I got worried.

The most common security breach in telecommunications is eavesdropping. Steganography and cryptography applied to telecommunication would both prevent that, the first by hiding the information, the second by talking in a language unknown to a third party listening. However, steganography is obviously more bandwidth demanding than cryptography, so why would anyone favour steganography over cryptography, when both achieve the same goals? Steganography has advantage that you can deny the existence of a hide message. Cryptographers call that plausible denial or deniable encryption.

StegIT (german) is a project that aims to prevent steganography in telecommunications (they aim for GSM/UMTS/VoIP). It works by mixing inauditable white noise into the conversation, so these "low bit" channels become unavailable for encoding hidden messages. StegIt does not aim to detect steganography, but its approach is to add this white noise to all conversations by installing equipment at your phone carrier. (To the german-speaking reader: Notice the wording they use in the project description. They speak of "steganographic attacks", and preventing these "attacks". Do they just desperately try to get funding or do they actually believe that?)

My initial reaction to StegIT was: "Why should I bother to use the low bandwidth channels at all? I would just drop those inaudible parts from my data channel and use regular encryption". I would loose the plausible denial property though, but is there is scenario where I would need that property? Yes, when encryption itself is outlawed (or made useless by laws for on-demand decryption).

This would only serve the purpose that eavesdropping is always available to law enforcement. But the idea to outlaw encryption sounded to remote to me... until I started googling that topic. Legislation concerning encryption is far from uncommon, see Crypto Law Survey by Bert-Japp Koops, who also provides us with some nice graphics.

Do I want my national security research fund to support a project that only make scene in a scenario where the right to encrypt -- your own personal guarantee for privacy -- is restricted? Definitely not.