Good passwords are hard to remember.

A pattern that makes a password memorable

is likely to make it vulnerable to attack. If remembering one secure password is hard,
remembering many such passwords is entirely impractical. So people who have gone to
the eort of creating one good password use it for many dierent accounts. A security
breach anywhere that password is used means that the password is vulnerable everywhere else it is used.
It is much safer to have dierent passwords for every account. Then if one password is
compromised, the damage is limited to a single account. One way to accomplish this
would be to have software compute a password for each account by encrypting the
name of the account. For example, your password for Home Depot could be the result
of encrypting the text homedepot. This way accounts with dierent names would automatically have dierent passwords. (In practice, it might be possible but highly unlikely for two account names to result in the same password.)
If you generate your passwords this way, you have to trust the software that is generating them. What if that software turns out to have a security hole, either as a result of
malice or error? If you could carry out the encryption in your head, you would not need
to trust any software.
Is it possible to create encryption algorithms that a human can execute but that a computer cannot break? It doesnt seem at rst that this should be possible, but Turing
Award winner Manuel Blum believes it may be. He presented his proposed algorithm
at the Heidelberg Laureate Forum. He emphasized that his method takes a lot of
up-front eort to learn but then it can be carried out quickly. To prove this claim, he
demonstrated that at least one person has in fact used the method, namely himself! He
said he can usually come up with a password in under 20 seconds.

Manuel Blum
Credit: hl / Flemming

To use Blums method you must memorize two things: a random mapping of letters to
digits, and a random permutation of the digits 0 through 9. The random map and the
random permutation are your personal keys so you must keep them secret. They must
be truly random any pattern that makes them easier to memorize may make your
system easier to break and thats why this up-front memorization is hard. But it only
has to be done once.
Call your mapping of letters to digits f. You might have, for example, f(a) = 8, f(b) = 3, f(c)
= 7, etc. Since there are more letters than digits, some letters will be mapped to the
same digit.
Let g be the function that sends each digit to the next one in your permutation. So if
your permutation was 0298736514 then g(0) = 2, g(2) = 9, g(9) = 8, etc.
Now here is how you use the method to generate passwords.
1. Convert the name of your account to a sequence of n letters.
2. Turn this sequence of letters into a sequence of digits using your map f. Call this
sequence of digits a0a1a2an.
3. Compute b1, the rst digit of your password, by adding a1 and an, taking the last
digit, and applying the permutation g. In symbols, b1 = g( (a1 + an) mod 10 ).
4. Compute the subsequent digits by bj = g( (bj-1 + aj) mod 10 ).

So if your account name converts to abc in step 1, this becomes 837 in step 2. The rst
digit of your password would be 1 because the rst and last digits of 837 add to 15, and
g(5) = 1. The second digit would be 0 because the previously computed password digit,
1, and the second digit of 837 add to 4 and g(4) = 0. The third digit would be 3 because
0+7 = 7 and g(7) = 3. Thus your password would be 103. (In practice your account names
would need to map to more than just three characters, but using abc kept the example short.)
The way you create a sequence of letters for an account could be anything you like. For
example, you could add your dogs name to the end of every account name if youd like.
If a particular password is compromised, you could change your password by putting
something new on the end, say the name of your neighbors dog, and going through
the encryption process again.
This method only produces digits. If a particular account requires, for example, that all
passwords contain a letter and a punctuation mark, you could stick an arbitrary xed
sequence like k$ on the end of the digits. If the digits produced by Blums algorithm
create a secure password, always adding the same characters on the end makes the
password no less secure.
Blums method is practical, though it takes memorization and practice. More generally,
it is an illustration of a research into the possibilities of human computation.

Bruce Grembowski
Shouldnt the second digit of the password for abc be g(1+3) = g(4) = 0?

John D. Cook
Bruce: You are correct, and my error in the second digit caused the third digit to be wrong. Ive submitted a correction
to be posted.

Phil Bewig
I agree the example is incorrect. I compute the hash of abc as 103.

Gnurf
A good idea in theory, but I see problems that make this not practical:
you have to remember the account names (ex: is it gmail or googlemail)
some sites enforce (annoying) policies about how your password should be formatted. Adding k$ will only work
when the site requires one letter and one non-alphanumeric character. But then some will require capital letters, or n
dierent digits, etc It is impossible to predict beforehand a single sux that would suit all such policies you could
ever encounter
even then, sometimes sites could force you to change your password (either they suspect they have been
compromised, or they just have a policy of forcing you to change regularly), and with a hard site->password
mapping, you cannot do that

manuel blum
Re 1st comment: by using the domain name as challenge e.g. fedex for fedex, ebay for ebay, etc, one avoids this
problem.
Re 2nd comment: its easy to change a password by attaching a digit to the challenge:
MAGIC1 -> 4 3 6 1 1 5
MAGIC2 -> 2 9 2 8 4 9
MAGIC3 -> 9 8 4 2 3 9
MAGIC4 -> 1 2 3 4 0 4
MAGIC5 -> 3 1 1 5 7 5
MAGIC6 -> 6 0 9 0 9 2
MAGIC7 -> 0 4 0 7 8 2
MAGIC8 -> 7 7 8 6 5 8
MAGIC9 -> 5 6 5 9 2 7
Re 3rd comment:
You are absolutely right. Remembering the original password requirements (length, allowed characters, characters not
allowed) can be a pain. This will be a problem until sites requesting passwords remind users of their requirements.

todd smith
The method as explained in the lecture doesnt meet reasonable security concerns. For example, on one slide there a
number of plaintext/ciphertext pairs:
BRAIN -> 06076
TRAIN -> 27732
GRAIN -> 35618
DRAIN -> 54349
From these four pairs one can deduce enough information about the mapping g( ) to determine the hidden secrets. In
this case, the permutation cycle that determine g( ) is:

(8, 1, 0, 6, 2, 7, 9, 3, 5, 4 )
with g( ) it is now easy to decrypt the rest of the system.

John Cook
Todd: In that example, you have a chosen clear text attack, and Blum did say that the method is vulnerable to such an
attack.
I dont think he mentioned that in his lecture. I had lunch with him some time later and he said that he wished he
could give a list of pros and cons of the method, but that would be too much for the time allowed. He did mention
chosen text attacks as a con.
In the context of a password scheme, however, youre not obligated to give an attacker encrypted versions of chosen
text. If you start with domain names, and you have accounts on four domains that dier only in their rst letter, and all
four are hacked, and someone has access to your passwords on all four sites, then youre in trouble, though thats
far-fetched.

todd smith
Yes, John, youre correct that those four plaintext/ciphertext pairs are convenient for determining g( ), but the method I
used is so simple that I did it on a few pieces of paper by hand. The key observation is that letters appearing more than
once in a single plaintext/ciphertext pair or repeated across a few plaintext/ciphertext pairs reveal enough information
to attack the system. This is not a chosen plaintext attack.
For example, DRANA -> 8 1 2 4 3, by itself reveals that g( 1 + f(A) ) = 2 and g( 4 + f(A) ) = 3. Since there is one k in {0,,9}
such that g(k) = 2, we can conclude that g(k+3) = 3. I found it easy to reconstruct g( ) by hand using such relationships.
It wouldnt take more than a few 8 character domain names to limit g( ) to a number of possibilities that could be
rapidly tested by a computer program. Once this is done, the system is eectively broken.
Further, consider a plaintext like DRANAGA, it has ciphertext 8 1 2 4 3 9 8. Notice that this gives away the cipher text
for DRANA.

grymlord
a workaround for the letter-to-digit mapping without brute memorizations would be to use a cyclic generator mod 9,
e.g:
A: 15 mod 9 = 5
B: 25 mod 9 = 1
C: 35 mod 9 = 6
D: 45 mod 9 = 2
etc.
you could use the same technique to generate a g() permutation.
17 mod 9 =7
27 mod 9 =5
37 mod 9=3
47 mod 9=1
etc

the multipliers need to be relatively prime to 9 (ie, 2, 4, 5, 7, 8)

Geek
The problem is that the security inherent in the random number generator is reduced to 5 choices, giving the
password <3 bits of entropy!

scht
Is there any posted-online analysis of this particular algorithm? Mainly Im interested in humane hashing or humane
psuedorandomnumber-generating algorithms for non-cryptographic purposes, although if there are good humane
algorithms for cryptogrpahic purpose, Id denitely be interested. I doubt/hunch that this one is good for
psuedorandom number generating.
Also, how should the random map be generated? The 26 letters vs 10 numbers thing presents an issue that can be
done a couple dierent ways (I dont know which is best/intended). Each letter independently randomly assigned a
number (allowing more than minimum collisions or missing values), or bijection with the numbers 1-20 union six
random numbers from 21-30 and then modulating (minimum amount of collisions).
I barely know about crypography (or even computer science in general).

scht
I also found these relevant https://xkcd.com/936/ and https://xkcd.com/792/. The strictly word-based password
scheme has the same fault of not having a capital letter, number, symbol, etc., and so I use the string-constant
appending scheme described on this article. As a play on of salt I sometimes call it pepper.

dieter
The mapping could be done with the aid of the QWERTY keyboard. It should be easy to memorize a random
permutation of keyboard keys by typing it out frequently, just like a password.
1. Permutate the website name in QWERTY-space
2. Use the digit row to map to digits. e.g. Q,A,Z -> 1; W,S,X -> 2; etc.
In fact, the addition could be done in QWERTY-space too, so we dont even need a mapping into the numerical domain.
Each key can be described as a three-dimensional vector (column, row, case).
key1 + key2 = (column1, row1, case1) + (column2, row2, case2) = ((column1 + column2) mod 10, (row1 + row2) mod 4,
(case1 + case2) mod 2)
The addition of columns is aided by the digit row of the keyboard.
So the algorithm is reduced to:
1. b_1 = g(a_1 + a_n)
2. b_i = g(b_i-1 + a_i)
In other words:

1. Add the rst and the last letter of the domain name.
2. Permutate -> password letter
3. Add next letter in domain name
4. Continue at step 2