I am looking for a cryptographic hash function that can be computed by a human using only paper and pen without ever leaking any information about the plaintext on the paper.

The cryptographic hash function should be computable by an algorithm satisfying the following properties:

Input/output: Any input/output set is acceptable as long as a human can represent and convert between that and text (e.g., base-2 <-> ASCII is acceptable).

Memory: Keeping in mind that humans can hold about 7±2 objects in working memory, the algorithm must require no more than 11 chunks (e.g., 11 digits, letters, or common words) of secure memory at any time. Data that do not need to be kept private can be offloaded to paper. Assume that the plaintext can be randomly accessed from secure read-only memory stored in the mind of the human.

Speed: The hash should be computable for a short input (say, 16 ASCII characters) in under a day. Under an hour would be great. Under a minute, fantastic.

Materials: Assume access to pen and paper. Precomputed tables (e.g., for S-boxes) are undesirable but acceptable; better would be tables that can be recomputed from easily-memorized compressed representations. Same goes for magic numbers or other precomputed data.

Security: The hash function should be preimage resistant. Second preimage resistance and collision resistance would be nice bonuses.

Side-channel attacks: The paper (or any medium other than the brain) must not at any time contain data that leaks information about the plaintext (burning the paper afterward is insufficient; assume that the state of the paper is monitored by an adversary throughout the computation).

Instruction set: The processing instrument is a human brain and operations must be executable by, say, a typical math/CS grad student (with practice). It may be useful to assume that the human can perform single-digit base-64 arithmetic (a set of $64^2$ mappings can be learned easily within a year through spaced repetition).

Description: It would be great if the algorithm can be memorized (along with representations of all precomputed tables and magic numbers). Otherwise, it would be best if a description fits on two sides of A4 paper (in words, diagrams, or anything else).

Current mainstream cryptographic hash functions are of course acceptable as long as there are algorithms that compute them satisfying the listed properties.

Esoteric instructions are acceptable. For example, if some part of the algorithm that requires a lot of secure memory can be done under a homomorphic scheme that requires little secure memory to execute (the idea being that everything can then be offloaded to paper without risk of leaking the plaintext), then go for it. (Something like this would presumably require a source of cryptographic randomness. That is okay: the human can memorize a high-entropy string known to no one else.)

For a less restrictive version of this problem, allow access to a modern computer, but assume that all input, output, memory, and instructions are monitored by an adversary (so entering sha512sum <plaintext> is not allowed because that leaks the plaintext). Use any standard Unix tool or language. Input and output are guaranteed to be untampered with.

I am looking for such an algorithm so that I can (re)generate high-entropy passphrases at will—even when I don't have privacy nor access to a secure computer—by memorizing a single high-entropy key and computing $\operatorname{hash}(\text{key}\mathbin{\|}\text{salt})$, where $\text{salt}$ is an easily guessable string unique to each passphrase.

There have been a few similar questions here on crypto.SE. Below I outline how this question is different from each of them:

Can you expand on why you have your side channel constraint? It doesn't seem to fit in with my model of what you're trying to achieve. The original (sensitive) information is on paper with the user. Why can they not create additional sensitive information and then either destroy it or leave it along with the original?
–
MichaelAug 17 '13 at 9:02

@Michael I'm not sure what you mean by the original sensitive information. I was thinking of a situation where the plaintext exists only in the mind of the user—it is not recorded anywhere else.
–
Vincent YuAug 17 '13 at 9:25

Aha, I understand. Might be worth incorporating that into the question - I interpreted the read only random access store as a piece of paper with the message on. If you have an example usage scenario in mind that would be interesting.
–
MichaelAug 17 '13 at 9:33

1

@vyu - if this has a practical application, please explain the environment a bit better: assume that you are in an insecure environment, and try to regenerate your PW. You would do this only in order to get back your private PGP/X.509 keys, and later use those keys to decrypt a ciphertext or deal with clear text. Either the decrypting of the keys using the regenerated PW or subsequent operations require a computer - and no more secrets on that computer, therefore it must be a secured computer. Why can't you also regenerate your hashed PW on that computer? Why only mental PW decryption allowed?
–
NinvehAug 17 '13 at 16:01

4 Answers
4

The paper (or any medium other than the brain) must not at any time contain data that leaks information about the plaintext.

Almost any security proof for a hash assumes an adversary only gets to see digests, not any mid-state. Mid-state has not had enough confusion and diffusion, so it leaks information.

This means that all secret state has to be kept in the mind, and all computations on the secret state have to be done mentally. Honestly, I think I can remember at most 8 numerical digits while doing a complex crypto routine on them (with pen and paper tracking progress throughout the routine). This means a security of ~26 bits max, so this can not possibly be secure.

And all that is assuming someone can actually describe a secure hashing scheme that can be done using mental operations.

I still don't understand your desire for a hash, especially considering (as already stated at other places in this forum) that you don't gain any entropy by subjecting a PW
to a deterministic function like a hash. So, when decrypting your ciphertext, you will be as secure with a H(key) as with (key), thus you might as well just memorize a good long passphrase + a random string for a good measure. I strongly feel that with such complex requirements and somewhat obscure thoughts one needs to meet face-to-face to really understand the nuances of the desired application.

With that said, I will now attempt to propose an algorithm that you may find useful to whatever you are trying to accomplish. It is not really a hash, but it may hopefully provide the mechanism you are looking for. I am using your terminology here - "key" as the input string and "passphrase" as the output string:

(Note: I will list the decryption phase only, working against an adversary. Encryption would be similar, but can be computerized as stated in the question)

Initialization:

Put a square matrix of random characters, 16 rows by 16 columns, totalling 256 chars, on a piece of paper

Learn and memorize the 7-bit decimals (or hex) ANSI equivalent of the 95 char sets (I assume you use the English language for your passphrase). Easy to do since they are sequential (can put the full ASCII table lookup on paper)

Learn and memorize the 7-8-bit decimals (or hex) representation of the characters in the random string (can put the full extended ASCII lookup table on paper).

Decryption (doing a streaming OTP + substitution):

Mentally split the key into its 2 distinct logical parts e.g Part A: "Johnny%rides" and Part B: "yellow+zebra"

Mentally take one character, at the same position in each Part, and convert to its hex equivalent. e.g. convert "J" and "y" to 0x4A and 0x79 respectively.
(it might have been easier to memorize the decimal equivalents, so in that case you should also go through the mental step of decimal -> hex)

Mentally take the hex value of the character of Part B, namely 0x79, and use its 2 hex elements as a (x,y) index into the written random table. Mentally pull out the random character from the cell and convert it to a hex equivalent.

Mentally take the hex value of the character of Part A, namely 0x4A, and perform XOR with the hex representation of the pulled cell value. In essence, doing OTP encryption between Part A of the key and a random value.

Use that hex value as the first character of your desired passphrase, writing it down and freeing your brain from remembering it.

Repeat the process with the next character of each part of the key, but with each successive character you need to increment the row from which you pull the random cell from, to thwart frequency analysis due to english words which are present in Part B - the index into the random table.

The above process requires minimal memory and mental load. When you are done, you will have your full passphrase. You can increase the size of the passphrase to double (or more) your Part A size by adding to each pulled cell value another cell value, say selected by a "knight move" from the first landing cell - as in a chess game.

Application Notes:

You can increase security if you prepare larger random matrix, and use 2 successive characters of Part B (mod table size) as an index.
Also, if practical, you should prepare several random tables and use them in succession - each associated with a different key.
The one random string you initially memorized can be used in a creative way - as an another index into the random table, concatenating or XORing with the results due to Part A etc.

Caveat: I hope that what I proposed here is to some extent what you were looking for. I haven't spent time analyzing the cryptographic strength of this proposal. It may have sever flaws, but this is the best I could come up with at a reasonable time.
Before putting it into practical use, you must evaluate its security, deficiency and usefulness.

No, there aren't any cryptographic hash functions like this. I'm pretty confident you're not going to find one. I have yet to see a white-box secure hash function that remains secure against dedicated attack, let alone one that you can implement securely on pencil and paper. Since this is a practical problem, I suggest finding another solution -- like hashing your passphrase on a computer you trust.

It wouldn't be too hard to write a custom Android/iOS app to do this for you, although whether you should trust a personal phone is another matter entirely. The truly dedicated could create a small hardware device with, say, an Arduino... sounds like a good spare-time project, actually.
–
ReidAug 18 '13 at 18:22

I stubled onto your answer to this question and decided to add its score. The answer is exactly correct, has mention of white-box, and correctly implies cryptographic hash functions are not designed according to this threat model.
–
user4982Oct 3 '13 at 18:05

He claims you have to spend an hour memorizing the technique and then you can apply the has function in about 20 seconds without even using pencil and paper.

The memorization required is to remember a random mapping of each letter of the alphabet to a digit in the range 0 to 9. You also need to remember a random permutation of the numbers 0 through 9. These stay the same for each string you want to hash so you only have to memorize them once. It's well within the ability of the average person to remember.

The hash function involves mapping the input string to digits, doing simple addition functions and then looking up values in the random permutation you memorized. He has a proof that it should be difficult for a computer to break the hash.

Is there a textual description of this hash function? I don't want to watch an hour long video for something that almost certainly doesn't meet the requirements of the OP. Learning to keep 60+ bits in mind at the same time is probably possible, but certainly takes quite a bit of effort.
–
CodesInChaosOct 30 '14 at 10:25

I was googling for a paper version of the algorithm when I found this question. Haven't found a paper yet. I edited my answer to include a few more details.
–
AaronOct 30 '14 at 23:47