Archive of old notes on encryption.

Old rant about the sorry state of PFS

On TLS and PFS Mike says

RSA key exchange provides up to 368 bits of security, but doesn't provide forward secrecy. If I want forward secrecy, then I need to use Diffie-Hellman. A server that has 1024-bit Diffie-Hellman parameters only provides me with somewhere in the neighborhood of 70-80 bits of security (extrapolated from the data in RFC 3526). You are saying that I am a "keylength fetishist" because I want better than 70-80 bits of security? So I'm allowed either lots of "strength" *or* forward secrecy, but not both? That's irresponsible.

Early warnings against the safety of X.509 certification

Fefe reports

In the wake of the Debian weak key issue it was revealed that whitehouse.gov had a weak key. It turns out that the Akamai SSL key is also weak. Akamai, in case you never heard of them, is a major content distribution network. They have tens of thousands of servers distributed over the world. If you have a high traffic web site, you can contract with them, and they will host it and redirect visitors to the site closest to them. Their customer list includes Microsoft, the New York Times, and -- particularly interesting for this -- ATI's driver downloads. Akamai obviously replaced their keys immediately. BUT. If you were quick enough, you could get their old public key (it is sent as part of the SSL handshake), and since the private key is weak (there are only 32k possible keys), you can generate the private key to it. Someone did (who wishes to remain anonymous) and sent the key to the CCC. I verified it. The key works. The part that has not sunk in yet for most people is: the public key is signed by a CA that browsers trust. I have a public key and a private key. I can now impersonate Akamai. If I can manipulate your TCP connection (which is easy, for example, if you are using Wifi or are on the same LAN with me), I can send you malware instead of the ATI driver. SSL has two defenses for this. First: keys expire. This particular key expires October 2008. Second: Certificate Revocation Lists. SSL originally had the idea that CAs would publish a list of compromised keys, and as part of the SSL handshake, the browser would check if the key is on the list. The problem is: that does not scale. At all. There are billions of SSL connections being established per second, Verisign can not possibly pay for the traffic to send their list to everyone. So -- noone checks the CRLs. This is the main reason why PKI does not work in practice. One more thing: I'd like to stress that Akamai did nothing wrong here. They did everything right and still have a problem. The same problem occurs if someone gets the private key by some other means, for example breaking and entering. The foundation upon which we build our infrastructure is less stable than most people realize.

One-Time Pad encryption

As implemented by http://pidgin-paranoia.sourceforge.net – this scheme generates one time encryption keys and requires you to install them manually on the communication partner's machine (transferring it by USB key or something), after that you can exchange a predefined number of messages, each encoded to a one time key, thus extremely hard to crack. Not very practical though. See also https://cryptoanarchy.org/wiki/One_Time_Pad

XMPP Encrypted Session Negotiation

Update: This stuff is discontinued. See OMEMO for current developments.

Ian Paterson has provided XMPP with several extension protocols, XEP-0116, XEP-0200, XEP-0217 and XEP-0187, which are directly inspired by OTR, and thus semantically very similar. XEP-0188 explains the maths behind things and gives OTR proper credit for its pioneering work. Let's abbreviate Encrypted Session Negotiation by calling it ESN here. The main differences to OTR are:

• ESN uses an XML-based protocol embedded into XMPP rather than something independent from transport medium like OTR. This may or may not be seen as cleaner, but that's certainly just a belly feeling - technically the overhead of using XML and no binary data makes these XEPs just as inefficient encodingwise as OTR.
• ESN has this 187 extension for leaving encrypted offline messages. It's a hack, but it's better than nothing. OTR has no such offering yet. This is a major cause for headache, as not being able to leave a message is very annoying. Probably the only real solution is to never log out and redirect your OTR messages to your mobile communicator instead. You should have a mobile phone you can trust, anyway. This is a separate problem which can be best addressed by an open-source mobile phone.
• While OTR currently only encrypts normal message body text, ESN can be applied to XML, thus encrypting richer data formats, like all the details of a presence packet. Unfortunately presence normally needs to be delivered by multicast to be scalable, which has encryption requirements not covered by neither ESN nor OTR (see further low for multicast encryption).
• More improved details that we overlooked.
• While OTR was designed by a cryptography professor, ESN is still in need of review. stpeter says "we basically can't get ESessions reviewed, which means we're flying blind to a large extent."
• Is there any implementation out there? Edit here.
• It's XMPP-centricness is somewhat limiting. However using PSYC's ability to deliver arbitrary XMPP packets, ESN should also work using ESN Jabber clients connected to psyceds in theory.
• According to the XEP, ESN is apparently designed to work together with OTR somehow, or to be able to carry it. It's not entirely clear.
• ESN also provides support for backdoors for legal reasons. That's not a nice thing to offer, then again - better to be warned of disclosure rather than to have no choice. Still, providing a disclosure flag will only help you in cases where the other side is willing to let you know about it. Finally, the OTR algorithms provide deniability, so if ESN correctly adapted the OTR principles, the disclosure of communications should be of no legal value and thus irrelevant as it could be purely fictional content.

Where was PSYC heading?

OTR is already very popular, in particular with the AIM/ICQ crowd. It is a good idea to start out with OTR (Dyskinesia implements that over PSYC for example), then there are some possible refinements:

• Both OTR and ESN protocols can be adapted for native PSYC encoding. This means that all binary data is actually delivered as binary, reducing the overhead of encrypted communications a lot.
• In both cases those encodings could be converted back to regular OTR or ESN if either legacy clients or networks require so.
• It's not a priority, it's a nice-to-have, unless we start to do some traffic intensive application with it like telephony.

But what is really interesting is to apply end-to-end cryptography to the entire PSYC packets and anonymize the routing. Luckily, with PSYC2 this comes natural. Also a really hot topic is the following:

Identity Protection

First of all, a passphrase should never be stored anywhere - making the private key usable is the job of the client. If we were to do server-based encryption in psyced, we could still let the final step be taken in a client - be it a web browser or a PSYC client. Ok, with the web browser it gets a little tricky.

Splitting identity is also a good plan (as suggested by el): You pick one server to hold your UNI for receiving messages, as always, but you also allocate an account on an alternate (secret) server, which only serves as to provide the PSYC client with private key and key ring. The client logs into both of these UNIs using the link procedure optionally enhanced by TLS, retrieves the messages from the first and the keys from the second (see Storage), then asks the user for passphrase and off you headstart into crypto communications.

Former Futures

See Software Projects for the idea of creating a Crypto Chatroom Server. No wait, the future has eaten itself. secure share is way ahead beyond that idea.

Thoughts

11:51:10 lynx sagt: hmm... userfreundlichkeit und cryptographie... das widerspricht sich ja oft
11:51:34 lynx sagt: ein gedanke: wie kann man es anstellen, dass ein user sich an einen blitzeblankneuen rechner setzt
11:51:46 lynx sagt: ne software aus dem netz zieht und seine alte identität annimmt
11:52:00 lynx sagt: es ist den usern nicht beizubiegen, dass sie den private key selbst aufbewahren müssten
11:52:18 lynx sagt: also könnte man nur sowas machen wie den private key per passphrase geschützt auf dem eigenen server unterzustellen
    kuchn broeselt: wie waers, wenn clients aes/rindjael implementieren und der verschluesselte key so gespeichert wird? psyc bietet
                    doch ein storage-feature.. der admin des servers sieht da dann nix vom schluessel, der trotzdem
                    jederzeit ueber ein passphrase zum client des users kommen kann, waehrend der oeffentliche ueber
                    psyc von jedermann abrufbar sei.
    kuchn broeselt: aber fuer raeume, da ist asymmetrische verschluesselung doch nicht wirklich passend;
                    im kontext sollte dann wohl eher simmetrisch, da ist ein regelmaessiger keychange einfacher;
                    und dieser key koennte ja am server mit dem public key eines partizipierenden users verschluesselt werden..
                    (ersetzt diffie hellmann) just an idea..

Pass phrase management in the browser

This is an interesting trick that the freenigma system apparently implements. To make encryption for end users easy, they keep keyrings and secret keys on the server side. Still they manage to not store the pass phrase on the server. The pass phrase is applied to the secret key in the browser, making the data unusable to freenigma should a ever ask them to release their data. Unfortunately this isn't exactly true, as the browser still submits the passphrase to the server which then decodes the private key with it. So all an external force has to do to get to the identities is modify the process to log the passphrase. Concerning encryption in the web browser, have a look at http://secushare.org/end2end