A specter is haunting the small world of economists: the pseudonyms used from 2013 to 2023 to post messages on the Economics Job Market Rumors (EJMR) forum—which the site claimed were completely secure and guaranteed that the authors of the messages could not be traced—actually make it possible to identify the IP addresses from which those messages were posted. A recent article (“Anonymity and Identity Online,” by researchers Florian Ederer, Paul Goldsmith-Pinkham, and Kyle Jensen) details the method used to achieve this. The article highlights serious errors in the use of cryptography by the site’s administrator.
To understand what happened, let’s first consider the simplest form of encryption, letter substitution: each letter of the alphabet is replaced by another letter or by a symbol, and the secret key is the table of these substitutions. Anyone who has read Sherlock Holmes (The Dancing Men) knows that such a cipher can be cracked by noting that E is the most common letter, and then making inferences based on the words encountered.
In fact, if you always use exactly the same cipher to encrypt a message, you create a vulnerability: if you always use the same ciphertext for the plaintext “YES” and always the same ciphertext for the plaintext “NO,” someone eavesdropping on the conversation can quickly identify these responses. Therefore, when encrypting a message, we usually prefix it with randomly generated data, so that the ciphertext depends on this data and we obtain two different ciphertexts when encrypting “YES” twice; this data is discarded during decryption.
In the process used by the EJMR website, the user’s IP address (a string of numbers assigned to them by their Internet service provider) was combined with the topic of the discussion in which they were participating, then fed into a cryptographic hash function (not encryption, but the difference between the two is irrelevant to the vulnerability of the process), without any additional data being added. This combination was achieved simply by concatenating the two, which the authors of the article quickly discovered. Next, the user’s pseudonym in the discussion thread was formed from four digits extracted from the output of this hash function.
With this method, it is easy to verify whether a message could have been posted from a specific address: simply take that address, concatenate it with the discussion topic, run the entire string through a cryptographic hash function, extract the four relevant digits, and compare the result with the username identifying the person in that thread. The authors of the article did this for all possible addresses (there are about 4 billion) and all discussion threads. For each message and each thread, they thus identified the possible addresses from which it could have been posted. This yields, for each message, approximately 65,000 possible source addresses.
One might think that having a list of 65,000 possible addresses doesn’t pinpoint the perpetrators. But just as with the riddle of the dancing men—where Sherlock Holmes was able to exploit the fact that the same cipher was used for multiple letters and that these letters were meant to form words—here we can exploit the fact that the same user, at the same address, is likely to post messages on multiple topics. However, only a tiny fraction of Internet users post on EJMR. If the same address appears among the possible addresses for users posting on nearby dates across multiple topics on this site, then that is likely the address of those users.
[More than 85,000 readers rely on The Conversation’s newsletters to better understand the world’s major issues. Subscribe today]
The article then presents various analyses: some of the email addresses used belong to networks of prestigious U.S. universities or institutions; a proportion of the posts were racist and/or sexist in nature; and so on. It is this last point that may be prompting a reaction from some who would not want their vulgar remarks to be reported to their employer or publicly associated with them.
From the perspective of a computer scientist—and especially a cryptographer—the method used to anonymize, or rather pseudonymize, this site’s users was absurd. As soon as the article explains how the site worked, the die was cast: the attack was obvious. How is it that this pseudonymization mechanism was chosen?
Based on certain messages left by the site’s author, he was highly confident that it would be impossible to trace the addresses of the message authors—a belief likely based on the choice of a cryptographic hash function. These functions, in fact, are supposed to be one-way : it is not possible to reconstruct the original data. However, this is true only if these functions are used properly; in this case, for example, a secret key—known only to the site administrator—should have been added to the data.
The moral of this story is that, while cryptographic tools are now widely available through programming languages designed for a broad audience, these tools are difficult to use. It’s often said, “Don’t roll your own security” —“don’t implement security mechanisms of your own design”—especially when it comes to individuals or companies whose area of expertise isn’t security or cryptography.
In some cases, we can actually be grateful for the perpetrators’ incompetence. For example, a 2016 study found that many pieces of malware—that is, software used for malicious purposes such as hacking, extortion, and so on—contain errors in their use of cryptography. The authors attribute this to the fact that malware creators use cryptography based on intuition and superstition, and jump at the chance to reinvent the wheel (proposing their own solutions to problems that are already well-known and well-addressed, for which very suitable solutions already exist), as well as to use pre-existing software components that are designed to solve problems other than the one at hand. Furthermore, they bluff in order to discourage victims.
Unfortunately, cryptographic vulnerabilities caused by careless software development or modifications are not limited to malware. A famous example is the discovery in 2008 that, since 2006, the cryptographic key generator in the OpenSSL library distributed with the Debian Linux operating system (and others based on it, such as Ubuntu), instead of generating keys randomly from a vast space, actually generated them in such a way thatone only needed to try them all to perform actions that are normally prohibited (such as intercepting communications with secure websites, etc.).
This fiasco was caused by changes made to the software by people who did not understand how it worked, as well as communication problems with the software development team.
Returning to the EJMR forum, this incident should prompt us to take a critical look at the security claims (“military-grade cryptography,” “unbreakable,” etc.) made by service providers, websites, and vendors that are not based on public, documented studies.
