At least since 2005 it's well known that the cryptographic hash function SHA1 is seriously flawed and it's only a matter of time until it will be broken. However, it's still widely used and it can be expected that it'll be used long enough to allow real world attacks (as it happened with MD5 before). The NIST (the US National Institute of Standards and Technology) suggests not to use SHA1 after 2010, the german BSI (Bundesamt für Sicherheit in der Informationstechnik) says they should've been fadet out by the end of 2009.

The probably most widely used encryption protocol is SSL. It is a protocol that can operate on top of many other internet protocols and is for example widely used for banking accounts.

As SSL is a pretty complex protocol, it needs hash functions at various places, here I'm just looking at one of them. The signatures created by the certificate authorities. Every SSL certificate is signed by a CA, even if you generate SSL certificates yourself, they are self-signed, meaning that the certificate itself is it's own CA. From what I know, despite the suggestions mentioned above no big CA will give you certificates signed with anything better than SHA1. You can check this with:
openssl x509 -text -in [your ssl certificate]
Look for "Signature Algorithm". It'll most likely say sha1WithRSAEncryption. If your CA is good, it'll show sha256WithRSAEncryption. If your CA is really bad, it may show md5WithRSAEncryption.

When asking for SHA256 support, you often get the answer that the software still has problems, it's not ready yet. When asking for more information I never got answers. So I tried it myself. On an up-to-date apache webserver with mod_ssl, it was no problem to install a SHA256 signed certificate based on a SHA256 signed test CA. All browsers I've tried (Firefox 3.6, Konqueror 4.3.5, Opera 10.10, IE8 and even IE6) had no problem with it. You can check it out at https://sha2.hboeck.de/. You will get a certificate warning (obviously, as it's signed by my own test CA), but you'll be able to view the page. If you want to test it without warnings, you can also import the CA certificate.

I'd be interested if this causes any problems (on server or on client side), so please leave a comment if you are aware of any incompatibilities.

Update: By request in the comments, I've also created a SHA512 testcase.

Update 2: StartSSL wrote me that they tried providing SHA256-certificates about a year ago and had too many problems - it wasn't very specific but they mentioned that earlier Windows XP and Windows 2003 Server versions may have problems.

Gestern habe ich den Versuch unternommen, in einem Vortrag ein paar Hintergründe über Kryptographie zu vermitteln, u. a. mit dem Versuch, einen Diffie-Hellmann-Schlüsselaustausch mathematisch zu erklären.

Die Folien gibt's hier.

Recently, two publications raised awareness of a problem with ssl secured websites.

If a website is configured to always forward traffic to ssl, one would assume that all traffic is safe and nothing can be sniffed. Though, if one is able to sniff network traffic and also has the ability to forward the victim to a crafted site (which can, e. g., be just sending him some »hey, read this, interesting text« message), he can then force the victim to open a http-connection. If the cookie has not set the secured flag, the attacker can sniff the cookie and take over the session of the user (assuming it's using some kind of cookie-based session, which is pretty standard on today's webapps).

The solution to this is that a webapp should always check if the connection is ssl and set the secured flag accordingly. For PHP, this could be something like this:

if ($_SERVER['HTTPS']) session_set_cookie_params( 0, '/', '', true, true );

I've recently investigated all web applications I'm using myself and reported the issue (Mantis / CVE-2008-3102, Drupal / CVE-2008-3661, Gallery / CVE-2008-3662, Squirrelmail / CVE-2008-3663). I have some more pending I want to investigate further.

I call security researchers to add this issue to their list of common things one has to look after. I find the firefox-extension CookieMonster very useful for this.

The result of my reports was quite mixed. While the gallery team took the issue very serious (and even payed me a bounty for my report, many thanks for that), the drupal team thinks there is no issue and did nothing. The others have not released updates yet, but fixed the issue in their code.

And for a final word, I want to share a mail with you I got after posting the gallery issue to full disclosure:
for fuck's sake dude! half of the planet, military, government, financial sites suffer from this and the best you could come up with is a fucking photo album no one uses! do everybody a favor and die you lame fuck!

I just read an article about the recent wordpress vulnerability (if you're running wordpress, please update to 2.5.1 NOW), one point raised my attention: The attack uses MD5-collisions.

I wrote some articles about hash collisions a while back. Short introduction: A cryptographic hash-function is a function where you can put in any data and you'll get a unique, fixed-size value. »unique« in this case scenario means that it's very hard to calculate two different strings matching to the same hash value. If you can do that, the function should be considered broken.

The MD5 function got broken some years back (2004) and it's more or less a question of time when the same will happen to SHA1. There have been scientific results claiming that an attacker with enough money could easily create a supercomputer able to create collisions on SHA1. The evil thing is: Due to the design of both functions, if you have one collision, you can create many more easily.

Although those facts are well known, SHA1 is still widely used (just have a look at your SSL connections or at the way the PGP web of trust works) and MD5 isn't dead either. The fact that a well-known piece of software got issues depending on hash collisions should raise attention. Pretty much all security considerations on cryptographic protocols rely on the collision resistance of hash functions.

The NIST plans to define new hash functions until 2012, until then it's probably a safe choice to stick with SHA256 or SHA512.

I recently took the new CAcert assurer test. Afterwards, one has to send a S/MIME-signed mail to get a PDF-certificate.

Having the same problem like Bernd, the answer came in an RC2-encrypted S/MIME-mail. I'm using kmail, kmail uses gpgsm for S/MIME and that doesn't support RC2.

While this opens some obvious questions (Why is anyone in the world still using RC2? Why is anyone using S/MIME at all?), I was able to circumvent that without the hassle of installing thunderbird (which was Bernd's solution).

openssl supports RC2 and can handle S/MIME. And this did the trick:

openssl smime -decrypt -in [full mail] -inkey sslclientcert.key

It needed the full mail, which took me a while, because I first tried to only decrypt the attachment.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
is all I have to say today.

Unter dem Titel »Hieroglyphen, Enigma, RSA - Eine Geschichte der Kryptographie« fanden heute an der Uni Karlsruhe zwei Vorträge, sowie eine anschließende Besichtigung der Sammlung von Klaus Kopacz.

Ich hatte zum ersten mal die Gelegenheit, originale Enigma-Maschinen zu sehen und bekam auch im Vortrag einen Eindruck, wie überhaupt genau der Verschlüsselungsalgorithmus der Enigma funktionierte.

Enigma-Bilder gibt's hier

Wie bereits angekündigt, treibe ich mich gerade auf den Metarheinmain Chaosdays in Wiesbaden rum. Location ist sehr ansprechend in einem Umfeld von grafittiverzierten, teilweise baufälligen Gebäuden und Kunstinstallationen (leider hat sich das Wetter gerade entschlossen, nicht sehr Foto-freundlich zu agieren und es sieht grad auch nicht so aus, als ob's heut nochmal Sonne gibt).

Aufgrund eines Vortragsausfalls habe ich spontan noch meine von der GPN übrigen Folien über XGL/AIGLX wiederverwertet und somit zwei Vorträge präsentiert.

Xgl-Vortrag das übliche staunende aah und ooh, die leidige Frage, was das bringt etc.

Der Vortrag über Passwörter brachte den gewünschten Widerspruch, insbesonder Fukami hielt heftig dagegen und konnte auch einige Dinge anbringen, die ich so noch nicht bedacht hatte, etwa die Frage, was es für Identitätsdiebstahl bedeuten würde, wenn man alle Zugänge per Chipkarten regelt.
Folien: OpenDocument, PDF

Anschließend hatte ich eine kurzweilige einstündige Unterhaltung mit einem Menschen einer wiesbadener Lokalzeitung, der schwer beeindruckt war, was ich ihm alles so erzählte. Insbesondere das »Ich kann deine eMails lesen« schien ihm nachzugehen (mit Live-Präsentation via Wireshark).

onlinetvrecorder, a service that let's you record broadcasts from some german television stations, provides it's files in .otrkey-format, which can be decoded using their binary otrdecoder-tool, considering you have requested the recording in advance.

As there is no information how the format and authentication work, I had a deeper look at it.

Getting the key

Using some network sniffer, the authentication is very simple, it just requests them with http, the URL is
http://www.onlinetvrecorder.com/uncrypt.php?email=[email]&pass=[pass]&filename=[file]
(filename is the .wmv-name without otrkey)
Inside that file is an ascii/hex-encoded number with 128 bit. That very much looks like a key.

This already gives us the possibility to manually download the key and, if we want to re-decode some movie (because we lost the wmv or because we want to decode a file before it's completely downloaded to already start watching the recording), save the key to a local webserver as uncrypt.php, forward the hostname to 127.0.0.1 and re-start otrdecoder.

The cryptography

From what I found out yet, the file is encrypted with some sort of blowfish. The encrypted and decrypted files are exactly the same size, that means we have no IV and a variant of blowfish that does no padding.

The best I got till now was using mcrypt with ecb-mode:
mcrypt -d -a blowfish-compat -s 16 -o hex -b --noiv -m ecb --nodelete -f [keyfile] [file]

This decrypts the first 256 bytes correctly, after that it seems to mix up things (the correct decryption continues at byte 512). From what I read in Schneier[1996] (»Applied cryptography«), there is an ecb variant using ciphertex stealing that avoids padding. I found no easy-to-use implementation of that.
Having a commandline-cryptography tool that supports more options than mcrypt would be handy here.

Today I held a talk about »Technical defense against surveillance« on an event with rather non-technical visitors.

I noticed that we still really have a lot of problems when providing easy-to-use security.

Things like "yes, you can do gpg with jabber, but only with a few clients, there's also another thing called otr, that's better from a cryptographic point of view but it is not based on the gpg-key-infrastructure and it's also only supported by some (other) clients" are really horrible to say if you always fear that nobody understands you.

A short list of things that came me to mind:
- I found no easy way on encrypting partitions with linux. Maybe I missed something, but I googled for it, tried it in ubuntu, found nothing. Had to tell them "there are some console-apps, dm-crypt, cryptsetup, etc.".
- Apps should enable ssl by default. Servers should forbid login without ssl. No more pop3, smtp, imap, jabber, webmail, whatever-web-login without ssl-encryption.
- Jabber should have a standard for encryption, based on gpg, with the cryptographic features of otr.
- We need to get rid of all unsecure algorithms (MD5, SHA1, RSA/DSA/ElGamal with 1024 bit) by default (yes, I know I said this hundred times before). GPG still creates 1024bit DSA-keys.
- Things like tor could be integrated into distributions, to be enabled by a click or similar.

Just some random ideas. It is possible to create much more secure systems. We just need to do it.

(And to not only cry, I hope I'll find some time and motivation to push some of the things I suggested in the near future)

Second day, finally uploaded some pictures and just found some time to blog between two talks.

Yesterday the We lost the war talk. Maybe I'll write something more in german when I find time for it. In short: IMHO this was an obscure mixture of political nonsense. This should at least be clear when reading the article with similar content in the last »Datenschleuder«, where the author claims something like »till 9.11. hackers ruled the world and everything was good« (to cite, »The big corporations were at our merce, because we knew what the future would look like and we had the technology to built it).
Lars wrote very drastically about it.

Today, the first interesting talk was5 Thesis on Informational-Cognitive Capitalism. I think I didn't really get what the autor wanted to say (surely related to missing sleep and lack of motivation to listen to english), but he was at least quite entertaining.

Next was Hashing Trusted Computing by Rüdiger Weis, as always quite funny, Rüdiger maybe should become the first professional math comedian. The content is obvious, at least for regular readers of my blog: Trusted Computing is evil and SHA1 is broken.

There was a nice presentation by fukami and Markus Beckedahl about the Sony BMG rootkit. They presented a lot of information, Markus has also collected it in his blog.

Next one was Technological art off the trodden tracks by two media artists that presented art which is related to hacking subjects and suggested that media artists and hackers come more together to share thoughts and projects. I hope they'll put their materials online, they had a lot of videos from nice stuff.

Just came from Learning cryptography through handcyphers by Benno de Winter. It was a basic introduction to some simple algorithms, not really new to me, but the speaker was worth watching because of the fun factor.

More to come.

Just arirved at the 22th chaos communication congress. Together with Lars I took the Nachtzug from Augsburg.

We are in a very nice hostel called Generator Hostel, which is very nice for a quite moderate price. Although we arrived at 8 o'clock in the morning, we already could enter our rooms and get a breakfast on arrival day. Very recommendable.

Pictures will follow from time to time.

Bruce Schneier writes about Phishing attacks and that he wants financial companies to be responsible for phishing attacks.

This brought me to some thoughts about online banking security and secure authentication in general.
Today, most online banking goes through web interfaces. That's really horrible in the sense of security. I remember when I asked my local bank for an online banking account, they told me "hey, you just need a web browser to do this". They have better alternatives (HBCI), but they don't promote them to their normal customers.
With a web-interface, you only have a one-way-authentication (the user authentificates itself to the bank, but the bank doesn't) and that's the whole thing why phishing works. If there would be any mechanism that verifies the authenticy of the bank for the user (or, to be exact, his applications, because we all now that average users don't manage to do so), the whole phishing-stuff would be senseless.

Even the less secure variant of HBCI with keyfiles is much more secure than web-interfaces. For a successfull phishing-attack, a user would have to upload his keyfile - which he usually won't do, because he doesn't know where it is. But the most obvious way: Smartcards.
Smartcards can be a fine solution for various security problems - and it's not much more complex. Everyone knows that he has to put his bank card into a cash terminal, so why shouldn't the average user be able to put it in a computer slot? But hey, it's even hard to get smartcard-drives - I once asked in the Saturn (big german technology market), they don't sell them at all.
The right thing would be having smartcard-drives in computers by default - and having chipcards for various security-applications.

HBCI, for the ones who don't know, is a german standard for online banking - I wonder why there is no word-wide online-banking-standard yet - with a secure, open design and based on two-way-authentication, together with some easy-to-use standard applications for online banking installed on every PC. That would really help a lot.

As the German News-page Golem writes, Firefox is going to drop obsolete SSLv2 support in it's next version, because it has known vulnerabilities by design.
While this is in general a very good idea to make things "secure by default", it will probably lead to people crying "Firefox can't open URL xy any more". We have a vast number of deprecated servers, applications etc. that just don't support up-to-date security standards and weren't updated for ages.

Even SSLv3 supports a lot of weak ciphers, like Single-DES, RC4 etc., that are known to be broken for ages. Not to talk about things like RSA 1024 or SHA1, that are not yet broken in reality, but probably will be at some time in the future.
The implementation of secure standards in todays software is far away from what's neccessary for high security applications.

We need to get rid of all that old cruft. High security is possible with today's cryptography, but we have to use it and we have to design applications that use secure technology by default.

Soweit ganz nett hier, gestern hab ich mir n Vortrag zu elliptischen Kurven angeschaut, der ganz nett war. Heute gab's n interessanten Vortrag zu IPv6 mit anschließendem Workshop, wo ich erstmals IPv6 lokal bei mir am laufen hatte. Muss mich mal bei Gelegenheit drum kümmern, dass auch mein Blog über IPv6 erreichbar ist.

Gleich werd ich nen Vortrag zu kryptografischen Hash-Funktionen halten, die Folien gibt's hier schonmal als OpenDocument oder PDF.