Edit: My goal is to create a voting scheme that doesn't require a lot of crypto infrastructure to be deployed on the client side. Smartcards, and tokens are impractical for these purposes. I envision a user typing a "code" into a web browser (which is imperfect) and submitting the inputs. The code is either static, or with minimal circuitry that can be covered in epoxy and embedded in a card.

Ideally this code could manifest itself in a way that is non-linkable to the original voter. I would like these anonymised ballots to be publicly acessible for verification.

If I can somehow "convert" a human typeable code into Microsoft's UProve, then all my requirements would be solved.

Is it possible to create a ZKP (or comparable MAC scheme) that can be typed by a human with relative ease? What would that crypto system look like?

If I were to design a crypto system around what can be typed easily by a human, say 26 uppercase ASCII letters, or 16 mixed case letters I believe that leaves me with security of 2^92 bits of security.

  • How should I take this design detail and turn it into something that can be used into a ZKP?

For example, take an ECC key with n bits and simply sign data with my key. Or use that crypto material in a comparable standard such as UProve or PGP.

  • $\begingroup$ You mean that your human memorable thing encodes all the information, i.e., secret + parameters etc, required to conduct a ZKP (I assume some HVZKPK)? Why don't save these information somewhere (i.e., online) encrypted under a key derived from the human memorable string, i.e., using techniques like here or here? $\endgroup$
    – DrLecter
    Dec 9, 2013 at 16:31
  • $\begingroup$ @DrLecter I'll take a look at those papers, but I was thinking of something like TOTP, where the private key signs the current time in 10 minute intervals, and that output be 2^92 secure. Replacements for TOTP is what I was looking for $\endgroup$ Dec 9, 2013 at 16:38
  • 1
    $\begingroup$ Maybe you could describe in a bit more details what you are aiming to solve such that one can get an idea why you came up with ZKPs etc. I think this would make it much easier to come up with an adequate solution. $\endgroup$
    – DrLecter
    Dec 9, 2013 at 16:43
  • $\begingroup$ @makerofthings7 You want a verifier, given some earlier data, to be able to verify that the prover has the input, without revealing the input to the verifier? $\endgroup$
    – orlp
    Dec 9, 2013 at 16:43
  • $\begingroup$ @nightcracker , I suppose what I'm looking for is a "non-interactive" zero knowledge proof. $\endgroup$ Dec 9, 2013 at 16:51

2 Answers 2


The usual way to encode long random bitstrings, so that they can be easily memorized and/or entered by humans, is to break them into blocks of (typically) 10 to 12 bits and map each block to an entry in a fixed dictionary of common words. This approach is commonly used for secure passphrase generation, e.g. by Diceware, S/KEY and PGP.

Assuming an 11-bit (i.e. 2048 word) dictionary, which seems to be close to the "sweet spot" for English (in terms of difficulty of memorization per bit), you could compute a MAC of the current time using the shared secret key, truncate it to 88 bits and map these to a sequence of eight words for the user to enter.

Ps. The optimal choice of words to include in your list depends somewhat on the use case and especially the entry method you're envisioning. For typed entry, shortness is important, whereas for spoken entry you want longer words with easily recognizable sounds. For typed passphrase generation, I've personally found a good starting point to be the set of exactly 4-letter words in any basic English dictionary (which should give you around 2000 to 3000 words, depending on the size of the dictionary), optionally filtered to remove any inappropriate, obscure or confusingly similar words.

Edit: I didn't see your clarification before posting this answer. Honestly, I'm not sure if the method I describe will help you in your task "to create a voting scheme that doesn't require a lot of crypto infrastructure", but then, I'm not really sure what would, either. In the answer above, I implicitly assumed that storing the secret key and calculating the MAC would be done by a computer, with only the MAC entry stage being done by hand. If you want the MAC calculation to be done by a human too, this becomes a very different (and much more difficult) challenge.


My goal is to create a voting scheme that doesn't require a lot of crypto infrastructure ... I would like these anonymised ballots to be publicly accessible for verification.

It sounds to me like you want a end-to-end voter verifiable voting system. Some of them do require a lot of crypto infrastructure, but it sounds like several others already meet all your goals. In particular, it the ThreeBallot system seems to meet all your goals.

Ron Rivest designed the ThreeBallot voting protocol to be both anonymous and verifiable.

  • Ballots are generated normally, all of them identical except for a unique random number at the bottom of the ballot (a Version 4 UUID would be more than adequate for that number).
  • The polling station gives every voter exactly 3 blank ballots (rather than the traditional 1 blank ballot). Every candidate is listed on a separate row.

enter image description here

  • Vic votes by filling in bubbles. Vic votes FOR a candidate by filling exactly 2 bubbles on that row. Vic votes AGAINST a candidate by filling in exactly 1 bubble on that row.

  • A "checker machine" looks at all the bubbles and enforces various election-specific constraints (some elections allow a voter to vote FOR several candidates; other elections require a voter to vote FOR at most one candidate and AGAINST everyone else). Victor shows the checker machine only the bubbles (not the random number); the checker machine should make no recordings. If the 3 ballots are valid, the checker machine marks all 3 with a green stripe. Then Vic presses "1", "2", or "3" on the checker machine and it makes a (black and white) copy of one of the 3 ballots as a take-home receipt. Victor checks that the copy is filled in the same as the selected ballot.

  • Poll workers make sure all green-stripe-marked ballots are cast into the ballot box.

  • At the end of the election, the entire set of ballots cast is scanned and published on the bulletin board.

  • Vic looks at the random number on a take-home receipt and verifies that it has the same bubbles filled in as the published ballot with the same random number. If not, Vic takes the receipt to his favorite journalist as evidence of electoral fraud.

As you can see, the ThreeBallot protocol never uses "zero knowledge proofs" or "phrases with 92 bits of entropy that can be typed by a human", so either I'm mis-understanding your question, or perhaps we have another case of the XY problem common on Stackexchange.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.