The title may read like a contradiction, but I would like to know whether a cryptographic solution exists to the following problem:

Problem statement

Suppose Alice wants to write a document using a pseudonym, so that, in general, people cannot connect her with her work. However, Alice may want to convince Bob (with at least a high level of confidence) in certain situations that she indeed is the author. At the same time, Alice does not want Bob to be in possession of a proof linking the author to the work. That is, Alice does not want Bob to be able to convince Charlie that Alice is the author of the document.


This may be useful in a setting where, say, a programmer might wish to publish code, or information pertaining to security research, without publicly associating himself with the information. Nevertheless, when hunting for a new job, the author may want to convince prospective employers of his abilities, but not give them proof that could de-anonymize him to the public at large.

Amateurish thoughts

I am not a cryptographer, but here are my thoughts so far:

Alice chooses a pseudonym, along with an RSA keypair, and sets up a public repository on e.g. github, which acts as a trusted third party, proving that certain data had existed at certain points in time, and recording all public manipulations thereof. Alice signs all her commits with her private key, and at some point interviews with a new employer.

Alice might offer to log into her pseudonymous github account and make publicly visible changes, but the interviewer might argue that she shares her login info with someone else, who might use the account in other interviews.

So I guess that Alice would have to upload data early in her publication chain that is advertised as the only and definitive proof of identity (such that there are not multiple hidden proofs for various real names). She may, for example, upload a cryptographic hash of a string that contains her name, followed by a secret random string known only to her. However, if she gave that string to an interviewer, the interviewer might save that string and show it to others, who then would also be convinced of Alice's authorship. Alice could offer to enter the secret string into devices only she controls, but then the interviewer might object, as he has no proof that the program really does compute the intended cryptographic hash.

Is there a way to achieve what I am after? The fewer assumptions necessary (e.g. trusted third parties), the better!

  • Check out off-the-record messaging and ring signatures, you might be able to apply those ideas here.
    – Steve
    Commented Jan 10, 2019 at 17:28
  • This actually isn't that bad until you get to the "they could say you share the password with someone else" part. Which boils down to "they don't trust you" and in security/identity an explicit lack of trust is hard to overcome (I can always assume you're cheating and rarely can you definitively prove you aren't). Even the smartcard idea Connor lists below fails (you just trade the card when at home). If there is some basic trust, you could do a blind challenge-response signed by the same key. "If this is your repo, post a signed .txt file that has this code but not any personal ID info"
    – Ruscal
    Commented Jan 10, 2019 at 18:24
  • @Ruscal: I figued that this would complicate things quite a bit. This requirement is why I attempted, in my second-to-last paragraph, to establish publicly that a given ciphertext/hash is the only artifact used in proving authorship. Then, if it is near-certain that only one string could encrypt/hash to that artifact, having the string state "Alice is the author <random stuff>" would prove that there are no two people claiming authorship. I don't know if it can be made such that an interviewer cannot prove to third parties that Alice is the author, though.
    – RQM
    Commented Jan 10, 2019 at 19:43
  • That's why your challenge/response proof shouldn't include identity (don't say Alice). Instead Alice could tell Bob "I can prove this is my repo, every commit was signed with the same PGP key. Give me some totally random data (prefer a string) and I'll commit that with the same key and you can verify it." Bob can verify that his challenge was signed/committed, but a casual observer won't be able to read the now-public data and infer authorship (it doesn't say "Alice was here" it says "Byzq98#21-H3"). That doesn't stop Bob from telling everyone he knows, but you can never stop that.
    – Ruscal
    Commented Jan 10, 2019 at 20:00

1 Answer 1


I'm going start by summarizing your want.

You want to:

  • Publically share information
  • The cannot be definitively associated to you
  • Unless you are present to defend yourself
  • In a way that cannot be reproduced by someone else

The answer would be a hardware based security solution for authentication, and an authorization system that requires the hardware based authentication in addition to another authenticator type (Something you know, something you are). So let's play with Github, as an example.

Github today allows people to create a Multifactor logon experience with a device such as the Yubikey. By enabling this feature, the access to your account is secured with a private key which cannot be shared and exists solely within your device. This, in addition to your password will always be required to authenticate to Github which you could even set up with a pseudonym of your choosing.

Once this is set up, you will have the ability to provide non-repudiation at your demand. You logon when you want to, and the logs indicating account changes can verify you haven't just thrown on the key to be impressive. You can show explicitly when the account was MFA enforced and even the last few logons. All good things.

The benefits of this approach is that only the holder of the Yubikey can actually access the account. This provides you the opportunity to share the data publicly without losing the ability to control who owns the original repository. Your interviewer could not login as you to prove that they know who built it, though you won't be able to overcome any trust that may exist. Meaning, if I trust your interviewer and they share who you really are that's beyond your scope.

Let me know if this is heading down the right direction and I can ellaborate further.

(instructions for yubikey configuration: https://support.yubico.com/support/solutions/articles/15000006469-using-your-yubikey-with-github)

  • Thanks! Your summary is succinct, but what it does not seem to capture is this: I want to be able to convince someone that there are not multiple people who can authenticate as the author, possibly at different times and places. In your solution, Alice could hand her Yubikey to Bob, who could interview with another employer and pretend the work is entirely his, could they not?
    – RQM
    Commented Jan 10, 2019 at 19:39
  • 1
    I think you have to really consider the level of scrutiny that you’ll be under. No credential is safe from being reused. You could even go to lengths to enforce vein based hand authentication but then pass out a wax hand designed to spoof the original. All you need to demonstrate is that the level of difficulty to overcome an authentication factor is significant. MFA with crypto for ssh and https authentication seems to be sufficient for just about everything. Commented Jan 10, 2019 at 19:54
  • Connor is spot on. Every authentication scheme is underpinned on some implicit level of trust (you trust the actor, or you trust an intermediate verification agent, or you trust the hardware module, but you have to trust someone). If there is absolutely zero trust, then nothing you do can be beyond doubt. In that instance, I'd lock you in a room with a disconnected terminal and demand that you generate the code from scratch -- which (fwiw) is a horrible way to make an impression on a potential new programmer. Once you establish the base trust level, you can build the solution from there.
    – Ruscal
    Commented Jan 10, 2019 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .