English - 8

I'm still lagging behind a lot with blogging my trip. So I'll try to keep up a bit.

After Yekaterinburg and a more than two day long train trip, we arrived in Irkutsk (Иркутck) near lake Baikal. Irkutsk is a much more tourist dominated city, which you suddenly notice by the larger number of english speaking people.

What I found noteworthy: At the beginning of our trip, I didn't see much of extreme poverty. This changed in Irkutsk. Large parts of the city are very small houses often in very bad shape. There are very rough breaks - in the same street, you see very modern buildings and a few meters further you see barracks. Also, there were a lot of burned down houses.

I took the opportunity in Irkutsk to visit the water power plant. It seems not many people consider it an interesting sight, as i was completely alone when I walked on and beside the dam.

A nice thing to visit was the market in Irkutsk, however, one should be prepared to be spoken to permanently by people trying to sell something to you.

After a short stay in Irkutsk, we went on to lake Baikal and the village Listvijanka (Листвянка).

Pictures from Irkutsk
Pictures from water power plant and dam in Irkutsk

Large parts of our trip to Asia is on the famous Trans-Siberian Railway. It goes from St. Petersburg in the north-west of Russia to Vladivostok in the far south-east and has several sideways like the Trans-Mongolian line and the Trans-Mandshurian line to China. I started my Transsib-trip in Moscow and am currently in Ulan-Ude (Улан-Удэ).

Travelling in middle-Europe, one is usually not used to several-day long train tips. On our trip, we used only Platzkart (плацкарт), which is the 3rd and cheapest class which has a bed (on some parts you can get seat only tickets, which are even cheaper, but we always travelled over night, so this was no suitable option). Platzkart means that you're not travelling in small compartments, the whole carriage is one compartment with several beds in it. Although we read in several travelling guides that it's an uncommon option for European travellers, we found it quite satisfying.

Every carriage has usually two train conductors. Something common on russian trains is that you can always get hot water to make tea or packet soup. I read in advance that there are a lot of food facilities on the stations, but this turned out to be much less of an option than thought. There are usually only small kiosks which all have more or less the same offerings.

Our longest train-trip was from Yekaterinburg to Irkutsk, which took us more than two days. It was very exhausting and we plan to avoid any more train trips longer than 24 hours for the rest of our journey. We also had some unpleasant experiences with drunken fellow passengers.

Pictures from Train Yekaterinburg - Irkutsk

Update: What I forgot to mention that's very noteworthy: On our trip, the transsiberian train was always very sharp on its schedule, at maximum it was only minutes behind. Very remarkable for several day long train trips.

I am a bit behind with blogging my trip - not enough time, and if there's enough time, theres often not enough electricity or internet.

We stayed for two days in Yekaterinburg (Екатеринбу́рг), which is the first big asian city if you travel from Europe to Russia. Yekaterinburg is probably a place where international visitors rarely drop by.

We stayed at two couchsurfers who operate a vegetarian shop in an area where vegetarism is barely known at all. So if you are ever in Yekaterinburg and need some tofu or soy milk, be sure to visit their shop.

The most relevant and unpleasant event during our stay was our attempt to get a ticket for our further route. I first thought that this wouldn't be a big issue, as we can order online tickets. But, as I already mentioned before, this is not an option here. For reasons unknown to me, this only works if you board the train at its starting point. So we went to the train station to try to get a ticket. Without much knowledge of Russian language, this was a really tough task and took us several hours. We wrote down the train we wanted to take and some Russian sentences we took from a travel guide. We were sent from one counter to the other, several times the ticket counter closed or made a "15 minute" pause (which in fact were more like 45 minutes) just in front of us. All in all I don't really know when we started this, so I don't know how long it took, but after all, we had the tickets we wanted in our hands - and they were significantly cheaper than any online offer we saw.

Beside the ticket buying, which took us half a day and limited the time we had to see the city, some interesting places worth mentioning:
- Yekaterinburg has a very geekish sight: A keyboard monument (some websites like Wikitravel call it the QWERTY monument, but I don't know if that's its official name) - a big keyboard made of stones (map link).
- We were shown an old hospital that was closed about 10 years ago and is now a place where adventurous people do urban exploration and locals tell horror stories about hidden subfloors. Most of the building is in very bad shape and some fountains around it give it a very special atmosphere. A small part of the building however is still operational (I don't know the exact place, but it must be around here).

A common thing to see in Yekaterinburg are trolley busses - busses that uses overhead wires.

What I experienced the first time here was a kind of real-world spam that seems to be common in Russia: In the pedestrian area, many shops used sound systems for advertisement. So you hear a lot of music and loudspeakers telling you the latest cheap offers all the time. Very disturbing.

We've continued our trip to Irkutsk, but I'll write about that later.

Pictures from Yekaterinburg

After a 30 hour train trip, we arrived at Moscow Belorussky Terminal (Москва́ Белорусский вокзал). We stayed with some very nice Couchsurfers.

We stayed in Moscow for about two days. It'll mainly leave me with two impressions. First, Moscow is the most car-dominated city I've ever been (I've always considered Stuttgart and Berlin to be very car-dominated, but it doesn't compare). Big roads everywhere, loud and smoggy.

We stayed in Moscow at the 9th may, which is the most important holiday in Russia. It is the day that is known in middle europe as the 8th may due to timezone shift - the day the red army finally defeated Nazi-Germany. Since a few years, in Moscow there's a big military parade, which ends with a presentation of Russia's nuclear missiles. It gave me very mixed feelings. It's probably the best reason to celebrate that one can think of, though it seems wrong to me to celebrate nuclear missiles.

I read a lot that it's difficult for foreigners without russian language skills to get tickets at the station's offices. The offers you'll get if you book through travel agencies in Germany are usually totally overpriced and it's often impossible to book the 3rd class at all. We booked our tickets through Real Russia, a UK-based company selling tickets online. It's webpage is very useful, you can check train tables, fares and free space. We had no need to go anywhere or get the tickets via mail, as they just register our passport number and the train staff has a list with them, so your passport is your ticket. However, it seems this only worked for the first train and they don't offer that for the further trains.

Then we headed for the first part of the Transsiberian Railway - a 25 hour trip to Yekaterinburg (Екатеринбу́рг). While you can read in many travel guides that middle european tourists usually don't travel in the 3rd class, I was positively surprised by the quality. Everything was clean and nice. The only drawback: The bed was a bit short for my long legs. Luckily, I had the opportunity to get some more hours of sleep in a bed with an open end. Language was difficult: It seems nobody on the train was able to speak English or German. Everything went smooth, so there was no need for communication, but it may become difficult when problems arise.

While we're at it, a nice weblink: Google has the full transsiberian route on video with a map showing where you are.

Now we're in Yekaterinburg, shortly after the european-asian border. My first time in Asia.

Pictures from Moscow
Pictures from Berlin-Moscow train trip

Ever since I heared that it's possible to take a train from Москва́ (Moscow) as far as 北京 (Beijing), I knew that one day I wanted to do that trip. Today is that day. I'll head off for a trip on the landway to China.

Beside finishing my studies, the last months were filled with preparations for the trip. Getting a proper bag, deciding what to take and what not, vaccinations and getting all the Visa ready - which was the most tiring part, maybe I'll write in detail about that later.

I hope I'll find time to write some blogposts and post pictures (you'll find them here as soon as I made some).

Today I submitted my diploma thesis to my university.

The thesis summarizes several months of investigation of the Probabilistic Signature Scheme (PSS). Traditionally, RSA signatures are done by hashing and then signing them. PSS is an improved, provable secure scheme to prepare a message before signing. The main focus was to investigate where PSS is implemented and used in real world cryptographic applications with a special focus on X.509.

During my work on that, I also implemented PSS signatures for the nss library in the Google Summer of Code 2010.

The thesis itself (including PDF and latex sources), patches for nss and everything else relevant can be found at
http://rsapss.hboeck.de.

I have a magnet plate hanging over my desk. Usually, the normal magnets for that purpose you can buy in shops are of very low quality and not very strong and fail to hold more than a few pieces of paper.

I recently discovered a way to get much better magnets almost for free: From old harddisks. To open a harddisks, you will usually need some kind of Torx screwdriver. Inside, you will find one or two very strong neodym magnets, which were originally used to move the read head.

https is likely the most widely used cryptographic protocol. It's based on X.509 certificates. There's a living debate how useful this concept is at all, mainly through the interesting findings of the EFF SSL Observatory. But that won't be my point today.

Pretty much all webpage certificates use RSA and sadly, the vast majority still use insecure hash algorithms. But it is rarely known that the X.509 standards support a whole bunch of other public key algorithms.

I've set up a page with a couple of test-cases for less-often used algorithm combinations. At the moment, it's mainly focused on RSASSA-PSS, but I plan to add elliptic curve algorithms soon. As I won't get any certificate authority to sign me certificates with anything else than classic RSA, I created my own testing root CA.

I'd be very interested to get some feedback. If you happen to have some interesting OS/Browser combination, please import the root certificate and send me a screenshot where I can see how many green ticks there are (post a link to the screenshot in the commends or send it via email).

At the moment, I'm especially looking for people to test:

• Internet Explorer 9 on Windows 7
• Safari on latest MacOS X
• Internal browser on iPhone (I don't know if it's possible to install a new certificate authority there)

Pioneer One is a science fiction series. What's special about it: It's completely supported by donations and it's distributed via BitTorrent. It comes under a Creative Commons Attribution-NonCommercial-ShareAlike license.

I read about the first episode a while back, but I forgot about it. Recently, I stumbled upon it again and took the opportunity to watch it. Up until now, just two episodes are completed, Episode three is announced for 28th of March and Episode four is in production. Further episodes will depend on the donations they get.

The rough story: A space ship is coming down over Montana and lands in Canadian territory. It spreads radiation, so the first suspicion is that it might be a terrorist attack. They find a probably russian human inside the ship, unconscious, with signets from the Sovjet Union. Their suspicion: The Sovjet Union has sent humans to settle on Mars and this one is a child coming back. The case is investigated by members of the US department of homeland security.

I found it pretty good. You can see overall that it's an independent production (for example the offices just don't look like offices from the US department of homeland security), but that makes no odds. The storyline is exciting, the actors do their job pretty well, the characters are interesting. My favorite character until now is Zachary Walzer, a scientist who's been endorsing Mars missions to the US authorities for a long time.

From the story concept, I'm not sure how this will make a very long series. At the moment it sounds like at some point they know what's going on and then it may not be interesting any more. Though there were some hints in which direction it might get to continue the story after that. I'm looking forward to see more.

If I raised your interest, go ahead and download Pioneer One.

The Electronic Frontier Foundation is running a fascinating project called the SSL Observatory. What they basically do is quite simple: They collected all SSL certificates they could get via https (by scanning all possible IPs), put them in a database and made statistics with them.

For an introduction, watch their talk at the 27C3 - it's worth it. For example, they found a couple of "Extended Validation"-Certificates that clearly violated the rules for extended validation, including one 512-bit EV-certificate.

The great thing is: They provide the full mysql database for download. I took the time to import the thing locally and am now able to run my own queries against it.

Let's show some examples: I'm interested in crypto algorithms used in the wild, so I wanted to know which are used in the wild at all. My query:

SELECT `Signature Algorithm`, count(*) FROM valid_certs GROUP BY `Signature Algorithm` ORDER BY count(*);

shows all signature algorithms used on the certificates.
And the result:

+--------------------------+----------+
| Signature Algorithm      | count(*) |
+--------------------------+----------+
|  sha512WithRSAEncryption |        1 |
|  sha1WithRSA             |        1 |
|  md2WithRSAEncryption    |        4 |
|  sha256WithRSAEncryption |       62 |
|  md5WithRSAEncryption    |    29958 |
|  sha1WithRSAEncryption   |  1503333 |
+--------------------------+----------+

Nothing very surprising here. Seems nobody is using anything else than RSA. The most popular hash algorithm is SHA-1, followed by MD5. The transition to SHA-256 seems to go very slowly (btw., the most common argument I heared when asking CAs for SHA-256 certificates was that Windows XP before service pack 3 doesn't support that). The four MD2-certificates seem interesting, though even that old, it's still more secure than MD5 and provides a similar security margin as SHA-1, though support for it has been removed from a couple of security libraries some time ago.

This query was only for the valid certs, meaning they were signed by any browser-supported certificate authority. Now I run the same query on the all_certs table, which contains every cert, including expired, self-signed or otherwise invalid ones:

+-------------------------------------------------------+----------+
| Signature Algorithm                                   | count(*) |
+-------------------------------------------------------+----------+
|  1.2.840.113549.27.1.5                                |        1 |
|  sha1                                                 |        1 |
|  dsaEncryption                                        |        1 |
|  1.3.6.1.4.1.5849.1.3.2                               |        1 |
|  md5WithRSAEncryption ANDALSO  md5WithRSAEncryption   |        1 |
|  ecdsa-with-Specified                                 |        1 |
|  dsaWithSHA1-old                                      |        2 |
|  itu-t ANDALSO  itu-t                                 |        2 |
|  dsaWithSHA                                           |        3 |
|  1.2.840.113549.1.1.10                                |        4 |
|  ecdsa-with-SHA384                                    |        5 |
|  ecdsa-with-SHA512                                    |        5 |
|  ripemd160WithRSA                                     |        9 |
|  md4WithRSAEncryption                                 |       15 |
|  sha384WithRSAEncryption                              |       24 |
|  GOST R 34.11-94 with GOST R 34.10-94                 |       25 |
|  shaWithRSAEncryption                                 |       50 |
|  sha1WithRSAEncryption ANDALSO  sha1WithRSAEncryption |       72 |
|  rsaEncryption                                        |       86 |
|  md2WithRSAEncryption                                 |      120 |
|  GOST R 34.11-94 with GOST R 34.10-2001               |      378 |
|  sha512WithRSAEncryption                              |      513 |
|  sha256WithRSAEncryption                              |     2542 |
|  dsaWithSHA1                                          |     2703 |
|  sha1WithRSA                                          |    60969 |
|  md5WithRSAEncryption                                 |  1354658 |
|  sha1WithRSAEncryption                                |  4196367 |
+-------------------------------------------------------+----------+

It seems quite some people are experimenting with DSA signatures. Interesting are the number of GOST-certificates. GOST was a set of cryptography standards by the former soviet union. Seems the number of people trying to use elliptic curves is really low (compared to the popularity they have and that if anyone cares for SSL performance, they may be a good catch). For the algorithms only showing numbers, 1.2.840.113549.1.1.10 is RSASSA-PSS (not detected by current openssl release versions), 1.3.6.1.4.1.5849.1.3.2 is also a GOST-variant (GOST3411withECGOST3410) and 1.2.840.113549.27.1.5 is unknown to google, so it must be something very special.

I already wrote in the past that a couple of times that I'm worried about the insane high energy consumption of DSL and WLAN hardware that's supposed to run all the time.

Recently, I switched my internet provider from O2 to Kabel Deutschland and got new hardware. I made some findings I found interesting:

It seems very many power supplies today have a label on their energy effiency. If you find something called "EFFIENCY LEVEL: V" - that's it. V is currently the best, I the worst. Higher values are reserved for the future (so this is much more intelligent than the stupid EU energy label, where A stands for "this was the best when we invented this label some years ago"). I haven't tried that yet, but from what I read it seems worth replacing inefficient power supplies with better ones.

The cable modem I got eats 4 Watts. Considering that it's the crucial part that cannot be switched off as long as I want to be able to receive phone calls, I consider this rather high. The power supply had effiency level IV. If anyone knows of any energy saving cable modems, I'm open for suggestions.

I was quite impressed by the router I got for free. It's a D-Link 615 and it's using 2,4 Watts with wireless and 1,4 Watts without. That's MUCH better than anything I've seen before. So at least we see some progress here. (and for people interested in free software: it seems at least DD-WRT claims to support it and the other *WRT projects are working on it)

Though I still fail to understand why there can't be a simple law stating that every electronic device must put information about it's energy consumption on the package.

If you've read my last blog entry, you saw that I was struggling a bit with the fact that I was unable to create a PGP key without SHA-1. This is a bit tricky, as there are various places where hash functions are used within a pgp key:

1. The key self-signatures and signatures on other keys. Every key has user IDs that are signed with the master key itself. This is to proofe that the names and mail adresses in the key belong to the keyholder itself and can't be replaced my a malicous attacker.
2. The signatures on messages, for example E-Mails.
3. The preference in side the key - this indicates to other people what sigature algorithms you would prefer if they send messages to you.
4. The fingerprint.

1 is controlled by the setting cert-digest-algo in the file gpg.conf (for both self-signatures and signatures to other keys). 2 is controlled by the setting personal-digest-preferences. So you should add these two lines to your gpg.conf, preferrably before you create your own key (if you intend to create one, don't bother if you want to stick with your current one):

personal-digest-preferences SHA256
cert-digest-algo SHA256

3 defaults to SHA256 if you generate your key with a recent GnuPG version. You can check it with gpg --edit-key [your key ID] and then showpref. For 4, I think it can't be changed at all (though I think it doesn't mean a security threat for collission attacks - still it should be changed at some point).

It is also not really trivial to check the used algorithms. For message signatures, if you verify them with gpg -v --verify [filename]. For key signatures, I found no option to do that - but a workaround: Export the key whose signatures you'd like to check gpg --export --armor [key ID] > filename.asc. Then parse the exported file with gpg -vv filename.asc. It'll show you blocks like this:

:signature packet: algo 1, keyid A5880072BBB51E42
	version 4, created 1294258192, md5len 0, sigclass 0x13
	digest algo 8, begin of digest 3e c3

The digest algo 8 is what you're looking for. 1 means MD5, 2 means SHA1, 8 means SHA256. Other values can be looked up in include/cipher.h in the source code. No, that's not user friendly. But I found no easier way.

The big question remains: Why is this so complicated and why isn't gnupg just defaulting to SHA256? I don't know the answer.

(Please also have a look at this blog entry from Debian about the topic)

Having used my PGP key 3DBD3B20 for almost eight years, it's finally time for a new one: 4F9F43A9. The old primary key was a 1024 bit DSA key, which had two drawbacks:
1. 1024 bit keys for DLP or factoring based algorithms are considered insecure.
2. It's impossible to set the used hash algorithm to anything beyond SHA-1.

My new key has 4096 bits key size (2048 bit is the default of GnuPG since 2.0.13 and should be fairly enough, but I wanted some extra security) and the default hash algorithm preference is SHA-256. I had to make a couple of decisions for my name in the key:
1. I'm usually called Hanno, but my real/official name is Johannes.
2. My surname has a special character (ö) in it, which can be represented as oe.

In my previous keys, I've mixed this. I decided against this for the new key, because both my inofficial prename Hanno and my umlaut-converted surname Boeck are part of my mail adress, so people should still be able to find my key if they're searching for that.

Another decision was the time I wanted my key to be valid. I've decided to give it an expiration date, but a fairly long one: 10 years from now.

I've signed my new key with my old key, so if you've signed my old one, you should be able to verify the new one. I leave it up to you if you decide to sign my new key or if you want to re-new the signing procedure. I'll start from scratch and won't sign any keys I've signed with the old key automatically with the new one. If you want to key-sign with me, you may find me on the 27C3 within the next days.

My old key will be valid for a while, at some time in the future I'll probably revoke it.

Update: I just found out that having a key without SHA-1 is trickier than I thought. The self-signatures were still SHA-1. I could re-do the self-signatures and revoke the old ones, but that'd clutter the key with a lot of useless cruft and as the new key wasn't around long and didn't get any signatures I couldn't get easily again, I decided to start over again: The new key is BBB51E42 and the other one will be revoked.
I'll write another blog entry to document how you can create your own SHA-256 only key.

Prologue of this story: A very long time ago (2004 to be exact), I decided to create a new PGP / GnuPG key with 4096 bits (due to this talk). However, shortly after that, I had a hardware failure of my hard disc. The home was a dm-crypt partition with xfs. I was able to restore most data, but it seemed the key was lost. I continued to use my old key I had in a backup and the 4096 key was bitrotting on keyservers. And that always annoyed me. In the meantime, I found all private keys of old DOS (2.6.3i) and Windows (5.0) PGP keys I had created in the past and revoked them, but this 4096 key was still there.

I still have the hard disc in question and a couple of dumps I created during the data rescue back then. Today, I decided that I'll have to try restoring that key again. My strategy was not trying to do anything on the filesystem, but only operate within the image. Very likely the data must be there somewhere.



I found a place where I was rather sure that this must be the key. But exporting that piece with dd didn't succeed - looking a bit more at it, it seemed that the beginning was in shape, but at some place there were zeros. I don't know if this is due to the corruption or the fact that the filesystem didn't store the data sequentially at that place - but it didn't matter. I had a look at the file format of PGP keys in RFC 4880. Public keys and private keys are stored pretty similar. Only the beginning (the real "key") part differs, the userid / signatures / rest part is equal. So I was able to extract the private key block (starting with 0x95) with the rest (I just used the place where the first cleartext userid started with my name "Johannes"). What should I say? It worked like a charm. I was able to import my old private key and was able to revoke it. Key 147C5A9F is no longer valid. Great!

P. S.: Next step will be finally creating a new 4096 bit RSA key and abandoning my still-in-use 1024 bit DSA key for good.

Yesterday I was at a talk at the FSFE Berlin about free software and GSM. It was an interesting talk and discussion.
Probably most of you know that GSM is the protocol that keeps the large majority of mobile phones running. In the past, only a handful of companies worked with the protocol and according to the talk, even most mobile phone companies don't know much of the internal details, as they usually buy ready-made chips.
Three free software projects work on GSM, OpenBTS and OpenBSC on the server side and OsmocomBB on the client side. What I didn't know yet and think is really remarkable: The Island State of Niue installed a GSM-network based on OpenBTS. The island found no commercial operator, so they installed a free software based and community supported GSM network.

Afterwards, we had a longer discussion about security and privacy implications of GSM. To sum it up, GSM is horribly broken on the security side. It offers no authentication between phones and cells. Also, it's encryption has been broken in the early 90s. There is not much progress in protocol improvements although this is known for a very long time. It's also well known that so-called IMSI-cachers are sold illegally for a few thousand dollars. The only reason GSM is still working at all is basically that those possibilities still cost a few thousands. But cheaper hardware and improvement in free GSM software makes it more likely that those possibilities will have a greater impact in the future (this is only a brief summary and I'm not really in that topic, see Wikipedia for some starting points for more info).

There was a bit of discussion about the question how realistic it is that some "normal user" is threatened by this due to the price of a few thousand dollars for the equipment. I didn't bring this up in the discussion any more, but I remember having seen a talk by a guy from Intel that the tendency is to design generic chips for various protocols that can be GSM, Bluetooth or WLAN purely by software control. Thinking about that, this raises the question of protocol security even more, as it might already be possible to use mainstream computer hardware to do mobile phone wiretapping by just replacing the firmware of a wireless lan card. It almost certainly will be possible within some years.

Another topic that was raised was frequency regulation. Even with free software you wouldn't be able to operate your own GSM network, because you couldn't afford buying a frequency (although it seems to be possible to get a testing license for a limited space, e. g. for technical workshops - the 27C3 will have a GSM test network). I mentioned that there's a chapter in the book "Code" from Lawrence Lessig (available in an updated version here, chapter is "The Regulators of Speech: Distribution" and starts on page 270 in the PDF). The thoughts from Lessing are that frequency regulation was neccessary in the beginning of radio technology, but today, it would be easily possible to design protocols that don't need regulation - they could be auto-regulating, e. g. with a prefix in front of every data package (the way wireless lan works). But the problem with that is that today, frequency usage generates large income for the state - that's completely against the original idea of it, as it's primarily purpose was to keep technology usable.