How does an anonymous persona verify its authenticity across channels?

Privacy Questions
1

how to maintain proof of authenticity of an anonymous persona across channels and usernames?

I am not a security professional. My understanding of cryptography comes from reading Neal Stephenson novels. I am pretty technically literate though and I have had this question stuck in my head and my web searches have not been able to find an answer. That may be because the answer is an obvious “that is not possible you moron” to those with enough knowledge to answer. Maybe no one has had reason to ask.

TLRD: how does an anonymous persona verify its authenticity across channels using different names?

Imagine a scenario in which an authoritarian regime takes over the Country. Crazy I know but bear with me. As this regime comes to power people find themselves targeted for retribution for speaking out. Students are targeted for protesting, opposition politicians are investigated, Legal non citizen residents are deported for speaking in opposition to the regimes view. People are angry but the fear is real.

Enter Jack, a concerned citizen who would like to share his thoughts online, against the regime. Jack is afraid that if his anti regime messaging draws too much attention he might find himself targeted for retribution. Jack is a moderately tech savvy person and researched how to create an anonymous persona and accounts for this persona on popular social media platforms. Jack begins posting as @theJackal. Jack feels safe to speak out, beings to do so and @theJackal forms a following.

The regime takes notice. “Who is this @TheJackal?” The regime demands of the social media platforms. The social media platforms are owned by wealthy child men who are afraid that the regime might make them less wealthy, or who are happily playing dictator themselves so they do whatever the regime wants. “We don’t know who @TheJackal really is, he created an anonymous account, but we went ahead and shut it down.” The social platforms respond to the regime.

Jack quickly creates @TheJackal2 and begins posting again.

The regime however is not as dumb as it looks on tv. The regime came to power by learning to manipulate and distort information and intersubjective reality to its advantage. So rather than engage in a cat and mouse game with @TheJackal 2,3,4,5. It uses what it has learned. Soon there are several other personas. @RealTheJackal begins posting in support of the regime. @TheJackAll begins posting some of the same things that Jack posts but also starts to throw in some racists memes, and conspiracy theories. Soon the people don’t know which persona was the original, and the signal is lost in the noise.

Question:
How can Jack prove his identity or authenticity as the original voice of @theJackal while assuming new screen names across channels? How does Jack prove his anonymous identity to the public while staying anonymous?

Is there an encryption scheme where everyone knows the message and can decode but only those holding the encryption key could encode the message. A sort of reverse public private key scenario?

What if …
early in @theJackals posting jack shared a decryption key and an identifying phrase “I am the Jackal”. The identifying message “I am the Jackal” and the decryption key and method are now public knowledge.

Jack uses an encryption that turn the message “I am the Jackal” into a “random” string of numbers and characters and posts that string at the end of his next message. The public reads the message and can decode the string and confirms that it contains the message “I am the Jackal”

Jack posts again and his encryption key and method turn “I am the Jackal” into another different “random” string, which decrypts via the public key to “I am the Jackal”

Is this possible in such a way that it is statistically highly unlikely that someone else could crack and mimic the encryption that turns “I am the Jackal” into a random string that can only be decrypted by the publicly known key?

2 Likes
2

This is generally done with something called a digital signature.

  1. Jack generates an RSA key-pair for signing messages. RSA-key size determines how strong the protection is, and the modern recommendation is at least 3072 bits. The RSA key-pair has a key that can encrypt short messages. This key is kept private. The other key of the key-pair can decrypt messages encrypted with the private key. This key is published to the world.
  2. Jack signs all messages by first using a cryptographic hash function, like SHA256, to generate a checksum called a hash. Modern cryptographic hash functions have a property called collision resistance that makes it impossible, even with a super computer, to produce another message, that has an identical hash. To complete the signing, Jack encrypts the hash of the message with the private RSA key. The encrypted hash is called the digital signature. Jack then publishes his message together with the digital signature.
  3. To verify a message was really generated by Jack, his readers decrypt the signature with the public RSA decryption key to obtain the true hash of the original message Jack signed. They then hash the message itself with SHA256 to get the purported hash, and then compare the two hashes. If the hashes match, they know the message originated from Jack, and that the message had not been changed.

It’s paramount that Jack keeps his private signing key, private. If it’s compromised, then the attacker can spoof Jacks’ publications.

Jack should also take into account that the system should provide some kind of timestamp or context information, to avoid someone just re-using e.g. a message he signed, where he simply replied “yes”.

All of these steps above can be handled with a protocol like PGP.

Non-repudiation

Note, that digital signatures come with the baggage of non-repudiation, meaning, if Jack is caught with his private key, it’s more or less impossible for him to deny he didn’t sign all those messages.

In the world of secure communication, this problem is usually addressed with message authentication codes (MACs) where both sender and recipient are in possession of key that can both sign and verify messages. This gives both parties plausible deniability, as neither party can claim their peer wrote that message, because they also have the keys necessary to produce the signature. (Note that courts do not really care about these protections, usually screenshots are considered valid evidence.) Jack can not use MACs to sign his messages, as then everyone had the key necessary to spoof messages, so he’s stuck with the problem of non-repudiation.

Protecting the private key

The private signing key is typically password protected (PGP clients like gpg by default prompt the user to enter a password). If the password is strong enough, and Jack can’t be compelled to hand it out with fines or in some authoritarian nations, torture, simply having access to the private key’s encrypted container on disk, doesn’t yet allow using it to forge new messages.

Note that key management of PGP-keys built into tools like gpg do not protect the information about which keys are installed. Command like $ gpg --list-secret-keys directly shows which keys the user has private keys for, which deanonymizes the writer of said messages.

Finally, there’s the question of how to prevent access to the authorship information of the private key, if the device is confiscated. This is done with operating-system wide full disk encryption (FDE). Most Linuxes allow setting up disk encryption during the OS installation.

Caveat emptor: if the attacker is able to hack the operating system remotely while you’re using it, they can obtain the key authorship despite you using full disk encryption.

Retiring the private key

When Jack decides to retire, he can — if he so desires — publish his private signing key, to prevent any third party from taking over. Jack must ensure his reader-base is aware of the publication of the private key, and the implications publishing it has. Whether he publishes it or not, Jack should reinstall his operating system some time later to remove traces of having written the messages.

Anonymous publishing

Publishing can be done pretty much on any platforms that allows registering and using via Tor Browser. There aren’t too many options, as most services don’t want to deal with propaganda, CSAM and other crap that it brings.

One option is https://onionshare.org/ that allows self-hosting an Onion Site, that the readers can then access with Tor Browser.

The nice part about this is, Onion Sites are as hard to spoof as PGP signing keys, so provided you use persistent onion service private key, you don’t have to use PGP to sign the messages. When someone bookmarks the onion-site, they know they’ll visit the same author’s blog every time. So you can just focus on hosting your own blog.

There’s some censorship resistance in that it’s hard for many state actors to determine which Tor user is hosting the site, but caveat emptor, if they manage to narrow it down, it’s not that hard to just cut the power to your house and see if the site goes down with your router handling the internet access. It’s been done before: Operation Lobos 1 - Wikipedia

2 Likes
3

Nice write-up!
This does two powerful things.

  1. Proves the plain-text of the message hasn’t been modified by a MiTm.
  2. Proves the holder of the private key was the author.