I am using Webalizer for accessing the logs of all virtual hosts on morrigan. Some time ago, I noticed that the logs were not being analysed completely. Instead, logrotate would cause the current log to be rotated away before Webalizer was able to record any changes.

The solution turned out to be very simple: Instruct Webalizer to use the old log file and enable its incremental mode. Thus, here is my updated configuration file (in excerpts):

LogFile      /var/www/bastian.rieck.ru/logs/access.log.1
OutputDir    /var/www/bastian.rieck.ru/stats
HostName     bastian.rieck.ru
Incremental yes

All configuration files are placed in /etc/webalizer, making it possible to create a cronjob that executes for i in /etc/webalizer/*.conf; do webalizer -c $i; done.

Posted late Wednesday afternoon, January 1st, 2014 Tags:

Startups and companies that aim to provide cryptographically secure internet messaging platforms have started cropping up during the last six months. This is a very good development. Unfortunately, cryptography is ridiculously hard to get right (provided that you are really starting from scratch, rolling your own algorithm that is only based on first principles). Cryptocat already got its share of criticism. A few weeks ago, I was very exited to learn about Telegram, an application geared towards providing a secure alternative to WhatsApp (these are my words, not the actual mission statement of the software). An initial post on Hackernews resulted in very mixed reviews. People were skeptical about some of the claims and the protocol choices made by the developers. Geoffroy Couprie wrote a long and detailed critique of Telegram, which has since been updated to contain new information. Personally, I consider his wording a bit harsh at times, but he makes some valid points. Paul Miller raised some equally valid points in a blog article, namely (among others) that it is easy to criticize people for doing something completely new. He has even been providing a live status of Telegram vulnerabilities.

With all these emotions flying around, I want to take a more diplomatic stance. In the best tradition of the mathematical crackpot index, Scott Aaronson's list of signs a mathematical breakthrough is wrong, and Jeff Atwood's collection of code smells in computer science, I decided to think about some crypto smells, i.e. signs that may indicate that a given cryptographic algorithm is overly hyped. This is not to say that every protocol that "smells" is necessarily wrong. It might explain why the Telegram experienced so much backlash, though.

Here's the crypto smells I have identified so far:

  1. Claiming credentials that are not related to the subject at hand. This is a classic variant of the argument from authority and is akin to using your professorship from Hogwarts to impress those muggles. Whether a cryptographic system is sound must depend only on its mathematics, not on the fact that it is created by John Doe, PhD.
  2. Bashing other cryptographic systems for their alleged complexity. While it is perfectly fine to claim that your product explicitly caters to non-experts, it is unnecessary to ridicule established algorithms such as PGP.
  3. Excessive use of buzzwords like military-strength encryption or adjectives such as unbreakable. Real science and scientific writing should be humble. Let your peers decide the worth of your application by showing them proof.
  4. Too many claims without proof. The description of your cryptosystem should be public. Do no behind empty phrases. This resonates with a previous article of mine on this subject.
  5. Not open-sourcing even the main algorithm. Given enough eyeballs, all bugs are shallow. Bugs in cryptographic applications have the highest potential for causing real damage. Any closed-source cryptographic application does not have any credibility at all.
  6. Using dated cryptographic functions (I am looking at you, MD5) in some places of the protocol. Good protocols might survive insecure components but this might still be indicative of a larger problem.
  7. Relying on central instances to perform auxiliary functions in the protocol. I am not talking about something like the PGP keyserves, which only serve to facilitate the existing protocol, but rather about something like a central server, for example, to broker between clients. Any central system smells fishy because it requires users to trust a central instance.
  8. Arranging a "crypto challenge" and claiming that the protocol is secure just because nobody solved the challenge. This is not the way it works.

That's all for now, I will expand the list if I identify any more smells. A very large and loud "Thank you" to all cryptographers out there. May your crypto always smell like roses.

Posted late Friday evening, January 3rd, 2014 Tags:

I recently got hold of some DVD .iso images of some live concerts. Naturally, I wanted to extract the audio streams to obtain some MP3 files. This turned out to be easier than expected. I first extracted the .iso image using tar (apparently, not all versions of tar can extract ISO 9660 images—luckily, the FreeBSD version can). I then used ffmpeg to extract the audio streams:

for file in *.VOB; do ffmpeg -i "$file" -ab 256k -f mp3 "${file%.VOB}.mp3"; done

This tells ffmpeg to create MP3 files with a bitrate of 256 kBit/s. Unfortunately, splitting required manual work because the live convert did not contain completely silent parts. Audacity proved to be useful here because it offers a spectral visualization which allowed me to quickly find the short speaking parts between two songs.

Readers from Germany, aufgemerkt: Obviously, the DVD image was created from one of my own DVDs. I am not inciting anyone to break the law.

Posted late Sunday evening, January 5th, 2014 Tags:

I just put the finishing touches (for now) on a small visualization project of mine. EtherCurve is a tool that uses a space-filling Hilbert curve to visualize packets in your network. Packets are scaled by their sizes and coloured using a qualitative colour map that can be custommized easily.

I wrote this mainly to get acquainted with libpcap and parts of Qt5. I also have a secret passion for fractal curves and yearn to use them in more projects. For my current research, they have already been of some use in a joint project, but the idea for EtherCurve is even older. As you can see from the git log, I wrote this more in spurts than in sprints...

See the project page of EtherCurve for usage instructions and related information (and some screenshots!) or take a look at the git repository of EtherCurve.

Posted Tuesday night, January 7th, 2014 Tags:

RC4 with TLS has been broken for quite some time now, but I did not yet manage to make the switch. Having a little time on my hands, I decided to future-proof my Apache configuration.

Basically, what I want to do is:

  • Disable ciphers for SSL that have known weaknesses. RC4, I am looking at you. DES, yes, you are meant as well. This includes ciphers that are marked EXPORT.
  • Use TLS 1.2 instead of the older versions.
  • Enable Perfect forward secrecy to annoy the NSA. Yes, using encryption might make you a target. They also admitted to storing encrypted session data with the express purpose of maybe being able to decrypt it after obtaining the private key of the server. Good luck with that.

It took me a while to collate the necessary information, but I finally managed to arrive at the following configuration for Apache:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
SSLCompression Off

Unfortunately, squeeze does not ship with OpenSSL 1.0 and Apache 2.4, which means that not all ciphers are currently supported. Thus, perfect forward secrecy will only work with a few choice browsers, but at least the configuration is better than it was before.

Some references which proved very helpful:

Posted Saturday night, January 25th, 2014 Tags: