A couple of months ago, many members of the cybersecurity community urged EU legislators to reconsider parts of the future eIDAS regulation. Since 2021, opposition has repeatedly been voiced by the industry, academia and NGOs.

The experts criticize the plan to mandate the (unconditional) inclusion of government-approved certificate authorities in the trust stores of all web browsers and thus shift control from tech companies towards governments.

The approach to anonymous credentials within digital wallets is also of concern. The regulation shall enable privacy-preserving technologies in certain scenarios, many in the cybersecurity community prefer to make them mandatory.

It appears that the EU refuses to budge and the scientists are not happy. Neither am I, but for different reasons.

Some three decades ago, Bruce Schneier famously wrote:

There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files.

I remembered the quote as I came across a (minor) government using the wrong kind of cryptography. As one would expect, they do have some reasonable security protocols in place. These are complemented, rather surprisingly, by several examples of cryptography your kid sister can break. Why cannot a government tell the difference?

I built a small encrypted VoIP system based on SIP. After a few experiments I settled for a Freeswitch server and Linphone clients and configured the use of ZRTP, probably the only reasonably documented interoperable protocol for encrypted calls. ZRTP offers what is now commonly called "end-to-end" encryption. The call is encrypted and the key is only available to the clients. Getting the system up and running was surprisingly easy, making it secure turned out to be a challenge. The way SIP and ZRTP are implemented in Linphone and other free software clients allows the server to listen to the calls.

A couple of days ago I wrote about universal ElGamal ciphertexts and about the importance of digital signatures. Although the story of a rather unremarkable piece of malware served us well as an example, it was not an example a reader could easily relate to or get their hands on. This time, I provide real-world examples in the form of actual messages and keys made of genuine bits.

ElGamal encryption is a mandatory part of OpenPGP, a comprehensive cryptographic standard also used to secure electronic mail. Until about 2009, ElGamal was the default public-key encryption method of GNU Privacy Guard, a free software implementation of OpenPGP. This text is about universal OpenPGP ciphertexts, fake encryption keys silently disabling encryption and about the importance of digital signatures.

In typical applications of cryptography, there usually are several distinct parties involved in a protocol. That might be part of the reason why cryptography has become so complicated. Even in simpler scenarios, where the sender and the recipient of a message are essentially the same person, there are applications for the arguably more advanced public-key primitives. There is also plenty of room for mistakes to be made.

Mallory has managed to install malware onto a machine she normally has no business of accessing. To carry out her evil plans, she has set up a way to control the victim machine remotely. She is able to send commands to and receive responses from the malware running there. This text is about the way Mallory applies cryptography to secure her messages.

It was recently revealed that the network of the Swiss company RUAG had been compromised. The GovCERT unit of the federal Reporting and Analysis Centre for Information Assurance MELANI was involved in the investigation and released a technical report on the espionage case.

On a few dozen pages, the document explains how the attack was probably carried out. The report also provides information on the malware used by the attackers. There is a rather remarkable five-page section on how a particular piece of malware implemented cryptography. Let us have a closer look at what GovCERT had to say and what was missing.