# How much entropy is generated by 'random' human keystrokes?

I'm wondering about using human input as an entropy generator. We all know humans are terrible at making up random numbers or keys or passwords. But what if we let a user 'randomly' type in some garbage. Just smashing the keyboard, so to speak.

How much randomness does that give, or rather, how much bits of entropy would it generate?

Obviously, way less than 2log(number of keys on keyboard), but I'd say 'a few' bits per keystroke feels about right? After one keypress, the next will be either a key close by (with another finger of the same hand) or one on the opposite side of the keyboard (with the other hand). So I would roughly guesstimate that at somewhere between 2 and 3 bits per stroke.

Any insights?

-
What do you consider for entropy extraction? Only the value received or do you also consider timing? Otherwise I'd always go with the most conservative approach acceptable (= 1bit / stroke?). But I don't have any actual stats about randomness of typing so no answer. – SEJPM Dec 1 '15 at 20:03
@SEJPM in a practical situation, I would consider not just keystrokes, but also mouse moves, internal cpu clock, accelerometer input (if available), and indeed also the timing of all user events, all at highest precision available. But for this theoretical question I was only wondering about keystrokes (regardless of timing). – RocketNuts Dec 3 '15 at 18:51

My approach would be to estimate the entropy empirically. Shannon attributes the term "entropy" to describe the irreducible information content of an information flow through a channel (as opposed to data flow). So it's the quantity of information. Some people disagree with Shannon's definition but let's ignore them :-)

2. Smash for the duration that you think a user will to complete the entropy generation process.

3. Repeat a 100 times. Do not just smash the keyboard for a 100 times longer, as you will not be modelling the actual start and end effects of the smashing.

4. Compress the recording with the strongest compressor you can find. I've found PAQ8 derivatives such as fp8 to be the best. They appear to be consistently 25% better than 7zip, which I find to be consistently better than zip.

5. The size of the resulting compressed file is the total entropy estimate. Divide by 100 and hey presto, your entropy per keyboard smashing session.

To guard against future improvements in compression technology, you might choose to divide the file size by a safety factor. I suggest 1.5.

Corollary: NIST produces useful information for general scientific usage, but be mindful of them cryptographically. There are articles in the Post regarding infiltration of NIST by the NSA as part of their Human Intelligence Programme. Clearly it's not in the Government's interest to have one part of it opposing the other.

-
Hey, thanks, that's an interesting approach. Might even do it through some form of 'survey', i.e. asking random people to enter pseudorandom content by smashing their keyboards and submitting whatever gibberish came out of that. Anyway finding out empirically by compressing the results seems a good indication to me. Going to look into this! – RocketNuts Dec 13 '15 at 9:14
Any way we can find out your results without upsetting Help Center? – Paul Uszak Feb 5 at 2:39

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

This publication from NIST tries to estimate the entropie of user choosen passwords. I know, it is not exactly what you requested, but i think it could be a good indication for the entropy of "random" keystrokes.

Especially Appendix A2 is relevant. The assume the following:

The first character is taken to be 4 bits of entropy The next 7 characters are 2 bits per character For characters 9 - 20 the entropy is taken to be 1.5 bits per character For characters 21 and above there is 1 bit per character

There is a "bonus" of 6 bits of entropy is both upper case and non-alphabetic characters are used

For more detail read the Appendix A.

-